Infinity (?!)

I would expect that it is valid for two NaN’s to equal each other, but
that because there are many different possible NaN’s, they need not
necessarily equal each other.

Paul

···

On Sat, Jun 01, 2002 at 11:27:23AM +0900, Sean Russell wrote:

Yukihiro Matsumoto wrote:

ruby -ve ‘p((0/0.0) == (0/0.0))’
ruby 1.6.7 (2002-03-19) [i386-linux]
false

Strange:

ser@ender rexml/rexml% ruby -ve ‘p((0/0.0) == (0/0.0))’
ruby 1.6.7 (2002-03-01) [i586-linux-gnu]
true

I tried the exact same command on my machine and got an inconsistent
result:

$ ruby -ve ‘p((0/0.0) == (0/0.0))’
ruby 1.6.7 (2002-03-01) [i686-linux]
false

···

On Mon, Jun 03, 2002 at 10:31:53PM +0900, Paul Brannan wrote:

ser@ender rexml/rexml% ruby -ve ‘p((0/0.0) == (0/0.0))’
ruby 1.6.7 (2002-03-01) [i586-linux-gnu]
true

Hi,

···

In message “Re: Infinity (?!)” on 02/06/03, Paul Brannan pbrannan@atdesk.com writes:

I would expect that it is valid for two NaN’s to equal each other, but
that because there are many different possible NaN’s, they need not
necessarily equal each other.

No, NaN should not be equal each other in any case, by its definition
(IEEE 754). I don’t know why Sean get “true”.

						matz.

I would expect that it is valid for two NaN’s to equal each other, but
that because there are many different possible NaN’s, they need not
necessarily equal each other.

I thought that it was part of the definition of NaN that it wasn’t equal
to any other number, including itself. So (despite Sean’s result) I would
expect:

ruby -ve 'p((0/0.0) == (0/0.0))'

to always return false.

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.

···

… How is a Texas tornado like a Tennessee divorce?
<|> Someone’s going to lose a trailer…
/|\
/|

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.

I see it too, though it’s ruby 1.6.4 on this machine:

irb(main):052:0> (0/0.0)==(0/0.0)
true
irb(main):053:0> (0.0/0.0)==(0.0/0.0)
true
irb(main):054:0> (0/0)==(0/0)
ZeroDivisionError: divided by 0
from (irb):54:in `/’
from (irb):54
$ ruby -v
ruby 1.6.4 (2001-06-04) [i586-linux-gnu]

While on a slightly more recent install:

$ ruby -v
ruby 1.6.5 (2001-09-08) [i386-freebsd4.4]
$ irb
irb(main):001:0> (0/0.0)==(0/0.0)
false

Rick

···


http://www.rickbradley.com MUPRN: 406 (92F/98F)
> It’s like having your
random email haiku | own private search agent 24x7.
> It’s quick. It’s easy.

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

···

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.


moved

Mit diesem Zeichen bann’Ich deinen Zauber!