Bug #7676

Comparison of Float::NAN in array behaves unexpectedly

Added by Simon Russell over 1 year ago. Updated 9 months ago.

[ruby-core:51328]
Status:Open
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:doc
Target version:next minor
ruby -v:ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux] Backport:

Description

It seems that two arrays containing Float::NAN will be considered equal ([Float::NAN] == [Float::NAN]), despite the fact that Float::NAN != Float::NAN.

Tested and reproduced in 1.8.7p371, 1.9.3p362, 2.0.0preview2. (This bug can be reproduced in Ruby 1.8 as well.) Results below.

1.8.7 p371

1.8.7 :001 > nan = 0.0/0.0
=> NaN
1.8.7 :002 > nan == nan
=> false
1.8.7 :003 > [nan] == [nan]
=> true

1.9.3 p362

1.9.3p362 :001 > Float::NAN == Float::NAN
=> false
1.9.3p362 :002 > [Float::NAN] == [Float::NAN]
=> true

2.0.0 preview2

2.0.0dev :001 > Float::NAN == Float::NAN
=> false
2.0.0dev :002 > [Float::NAN] == [Float::NAN]
=> true

bug-7676.patch Magnifier (1.67 KB) Charlie Somerville, 01/09/2013 11:00 PM


Related issues

Duplicates ruby-trunk - Bug #1720: [NaN] == [NaN] が true になる Closed 07/03/2009

History

#1 Updated by Charlie Somerville over 1 year ago

=begin
Attached a patch fixing this issue - the pointer equality checks in (({recursiveequal})) and (({rbequal})) should not be performed as this breaks in the case where (({a != a})).

I'm not committing this straight away because it causes three test failures due to brittle mocks.
=end

#2 Updated by Naohisa Goto over 1 year ago

  • Status changed from Open to Rejected

#3 Updated by Simon Russell over 1 year ago

This isn't just Float::NAN, actually; as Charlie's patch shows, it's actually any object that always returns false from ==

1.9.3p125 :001 > class X
1.9.3p125 :002?> def ==(other)
1.9.3p125 :003?> false
1.9.3p125 :004?> end
1.9.3p125 :005?> end
=> nil
1.9.3p125 :006 > x = X.new
=> #
1.9.3p125 :007 > x == x
=> false
1.9.3p125 :008 > [x] == [x]
=> true

Is this desirable behaviour?

#4 Updated by Simon Russell over 1 year ago

At the very least, the documentation for Array#== should be updated to state that it first does an object identity comparison, then calls == only if the objects aren't the same instance.

#5 Updated by Hiro Asari over 1 year ago

I, too, found documentation still lacking. I read #1720, and I understand the rationale for the Float::NAN case.

However, the issue still remains as Simon pointed out above. Please reopen the issue, or update the documentation to reflect the behavior more closely.

#6 Updated by Naohisa Goto over 1 year ago

  • Category set to doc
  • Status changed from Rejected to Open

#7 Updated by Kenta Murata over 1 year ago

  • Assignee set to Yukihiro Matsumoto
  • Target version set to next minor

I think this is the specification issue, so we need to confirm the mat'z thought.
Matz, how do you think about it?

#8 Updated by Charlie Somerville over 1 year ago

=begin
I understand that matz wants (({nan == nan})) to be undefined, but I think this should remain consistent within a platform, even though it is undefined between platforms.
=end

#9 Updated by Steve Klabnik 9 months ago

I would be happy to write a documentation patch for this if Matz can confirm which behavior is correct.

Also available in: Atom PDF