[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Bug in math library
From: |
Paul Schlie |
Subject: |
Re: [avr-libc-dev] Bug in math library |
Date: |
Sun, 09 Jan 2005 14:03:14 -0500 |
User-agent: |
Microsoft-Entourage/11.1.0.040913 |
>> 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".
- [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/08
- Re: [avr-libc-dev] Bug in math library, Marek Michalkiewicz, 2005/01/08
- Message not available
- Message not available
- Re: [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/08
- Re: [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/08
- Re: [avr-libc-dev] Bug in math library, Marek Michalkiewicz, 2005/01/08
- Re: [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/09
- Re: [avr-libc-dev] Bug in math library, Paul Schlie, 2005/01/09
- Re: [avr-libc-dev] Bug in math library, Paul Schlie, 2005/01/09
- Re: [avr-libc-dev] Bug in math library, Bob Paddock, 2005/01/09
- Re: [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/09
- Re: [avr-libc-dev] Bug in math library,
Paul Schlie <=
- Re: [avr-libc-dev] Bug in math library, Colin O'Flynn, 2005/01/09
- Re: [avr-libc-dev] Bug in math library, Joerg Wunsch, 2005/01/09