NaNs etc. once again. Was: Re: 5.1 and vc6

[Rici Lake <lua@...>]

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.