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

[David Burgess <dburgess@...>]

I think Roberto is correct in saying that this is an user implemetation
issue. I do not think you will find a generic solution. I have used used
brain dead systems that never generate NAN and INF but unconditonally
throw exceptions. In environments like this, adding constants to Lua
would not achieve much.  

DB

On Sat, 5 Mar 2005 12:55:32 -0500, Rici Lake <lua@ricilake.net> wrote:
> 
> 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.
> 
>