[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **NaNs etc. once again. Was: Re: 5.1 and vc6**
**From**: Rici Lake <lua@...>
**Date**: Sat, 5 Mar 2005 12:55:32 -0500

On 5-Mar-05, at 6:01 AM, Wim Couwenberg wrote:

`Another thing, related to the recent NaN discussion: the runtime libs
``of vc6 are broken in the sense that x ~= x is *false* for x a NaN. In
``fact x == y is *true* if either one of x or y is NaN. vc7 fixed this
``bug. In vc6 there is an _isnan function available in float.h or you
``could do something like
`
if x == 1 and x == 2 then ... -- x is NaN

`I found the following on google, which I haven't verified (since I
``don't have icc) but it demonstrates how difficult this sort of thing
``can be:
`
--------------------------
#include <stdio.h>
#include <math.h>
int main(int argc, char * argv)
{
double i = NAN;
printf ("The numbers are %s\n", (i == i) ? "equal" : "different");
return 0;
}
Some results:
$ gcc -o ieee -std=c99 ieee.c && ./ieee
The numbers are different
$ gcc -o ieee -std=c99 -ffast-math ieee.c && ./ieee
The numbers are equal
$ icc -o ieee ieee.c && ./ieee
The numbers are equal
$ icc -o ieee -ansi ieee.c && ./ieee
The numbers are different
------------------------------------

`It is probably impossible for a cross-platform scripting language to
``cope with all the variations of floating-point (non-)support.
``Nonetheless, I think there are a couple of things which would go a long
``way.
`

`First would be the convention that a NaN (if the underlying
``architecture supports it) tests false, and ideally, that using nil in
``an arithmetic operation has the same result as if it were NaN. This
``would allow programs to test for NaN in a reasonably obvious way, and
``also allow arithmetic functions to return a NaN-like object, without
``much dependency on the underlying architecture.
`

`Second would be the inclusion of infinity-like constants in the math
``library (which I would call infinity rather than HUGE_VAL, but maybe
``that's just me) which would at least have the appropriate behaviour
``with math.max and math.min.
`