Re: [avr-libc-dev] Bug in math library

[Paul Schlie]

>> From: Colin O'Flynn <address@hidden>
>> By the rigorous rules of mathematics "division by zero is undefined".
>> An exception should be thrown or flagged.   I do not know where
>> the common idea that division by zero results in the answer of  infinity
>> originated.
> 
> I assume from the fact that the limit of x / y, as y approaches 0 is infinity.
> However x/0 is in fact quite undefined, and IMHO it should always result in a
> NaN returned.

As zero is just an abstraction, +/-0 float values represent an infinitesimal
magnitude greater or lesser than an abstract zero, thereby may be thought of
as being equivalent to 1/(-> +/-inf); where if literally defined as being
equivalent within the range of represent-able values, then:

  x/0 = x/(1/(-> inf)) = x*(-> inf) = inf

Where as x -> 0:

 (1/(-> inf))/(1/(-> inf)) = inf/inf = 1

(which essentially eliminates useless "abstract zero" discontinuities,
 and complications, yielding expected equivalent ieee results to otherwise)

>              As long as the rest of the floating point routines respect this
> NaN, it will show up at the output of the system therefore alerting the
> programmer (or someone) that an illegal math operation was attempted and
> there is a bug somewhere.

The routines that may be simplified, are the routines you reference.

(unfortunately as NAN's or sticky inf's manifest themselves at run-time,
when it's typically too late in deployed code; it simply seems that it may
be more efficient to assume the interpretation above, as it would yield the
closest approximate useful result within the range of represent- able values
to begin with, rather than having to identify and then attempt to substitute
alternate useful values after the fact; but do understand your concerns.)

Sorry for the diversion, just meant to field a thought that may both
simplify float routine implementations and use, although "non-standard".