From: Kyle Rawlins <rawlins@...>
Date: 2002-06-04T05:34:17+09:00
Subject: Re: Infinity (?!)

On Tue, Jun 04, 2002 at 02:38:25AM +0900, Sean Russell wrote:
> Yukihiro Matsumoto wrote:
> > No, NaN should not be equal each other in any case, by its definition
> > (IEEE 754).  I don't know why Sean get "true".
> 
> Since I appear to be the only person who sees this, I'm guessing that my 
> Ruby installation is broken somehow.

If ruby is compiled (for whatever reason) with -ffast-math and any -O on gcc,
you might see this behavior.  That option tells gcc that it can violate IEEE
specs to be faster.  This option alone doesn't do it, but -O or -O2 etc in
conjunction seems to.  (I guess -ffast-math just allows optimization, but
doesn't do it)

At the heart of it (at least in 1.6.7) a ruby float is stored as a C double in
the RFloat struct, and comparison is eventually done using C '=='.  This should
either invoke glibc fp functions or possibly do the fp comparison directly.
The only way I could see ruby messing up is if its types were munged, resulting
in calling Object.== I think, but this seems very unlikely.

If you compile the following C snippet with optimization on and with and
without -ffast-math, you can see this happening.  If it prints true without
that option on, something is odd about your compiler or your glibc.  (There is
probably some equivelent option for other compilers, but I don't know it)

int main(int argc, char **argv)
{
    double x, y, n1, n2;
    x = 0.0;
    y = 0.0;
    n1 = x / y;
    n2 = x / y;
    printf("n1: %f, n2: %f, n1==n2: %s\n", n1, n2, (n1 == n2) ? "true" :
            "false");
}

[rawlins@ymir compiled]$ gcc -O test.c -o test && ./test
n1: nan, n2: nan, n1==n2: false
[rawlins@ymir compiled]$ gcc -O -ffast-math test.c -o test && ./test
n1: nan, n2: nan, n1==n2: true

I have no idea why ruby would have been compiled with this option though; it
probably shouldn't be ever.

hope this helps,
-kyle

-- 
http://mas.cs.umass.edu/~rawlins
--
Mit diesem Zeichen bann'Ich deinen Zauber!