Bug #1363

Wrong value for Hash of NaN

Added by Heesob Park almost 6 years ago. Updated almost 4 years ago.

[ruby-core:23154]
Status:Rejected
Priority:Normal
Assignee:Yukihiro Matsumoto
ruby -v:ruby 1.9.1p0 (2009-01-30 revision 21907) [i686-linux] Backport:

Description

=begin
Ruby cannot handle NaN as a unique key of Hash.

Here is an example:

irb(main):001:0> h = {}
=> {}
irb(main):002:0> h[0/0.0]=1
=> 1
irb(main):003:0> h[0/0.0]=2
=> 2
irb(main):004:0> h[0/0.0]=3
=> 3
irb(main):005:0> h
=> {NaN=>1, NaN=>2, NaN=>3}
irb(main):006:0> h[0/0.0]
=> nil

I think this is related with the NaN comparing problem:

irb(main):001:0> 0/0.0 == 0/0.0
=> false
irb(main):002:0> a = 0/0.0
=> NaN
irb(main):003:0> a == a
=> false
irb(main):004:0> a <=> a
=> nil
=end

History

#1 Updated by Nobuyoshi Nakada almost 6 years ago

=begin
Hi,

At Wed, 8 Apr 2009 14:38:31 +0900,
Heesob Park wrote in :

Ruby cannot handle NaN as a unique key of Hash.

It's easy to make them unique as key, I'm not sure which is
"correct" behavior though.

I think this is related with the NaN comparing problem:

irb(main):001:0> 0/0.0 == 0/0.0
=> false
irb(main):002:0> a = 0/0.0
=> NaN
irb(main):003:0> a == a
=> false
irb(main):004:0> a <=> a
=> nil

I think it's mathematically correct behavior, and different
thing from Hash.

Index: numeric.c
===================================================================
--- numeric.c (revision 23390)
+++ numeric.c (working copy)
@@ -1127,7 +1127,6 @@ flo_eql(VALUE x, VALUE y)
double a = RFLOAT_VALUE(x);
double b = RFLOAT_VALUE(y);
-#if defined(_MSC_VER) && _MSC_VER < 1300
- if (isnan(a) || isnan(b)) return Qfalse;
-#endif
+ if (isnan(a) && isnan(b))
+ return memcmp(&a, &b, sizeof(a)) ? Qfalse : Qtrue;
if (a == b)
return Qtrue;

--
Nobu Nakada

=end

#2 Updated by Yukihiro Matsumoto almost 6 years ago

=begin
Hi,

In message "Re: Re: [Bug #1363] Wrong value for Hash of NaN"
on Mon, 11 May 2009 19:03:59 +0900, Nobuyoshi Nakada nobu@ruby-lang.org writes:

|At Wed, 8 Apr 2009 14:38:31 +0900,
|Heesob Park wrote in :
|> Ruby cannot handle NaN as a unique key of Hash.
|
|It's easy to make them unique as key, I'm not sure which is
|"correct" behavior though.

Two NaN values are not equal with each other by definition, in that
sense, even though some might want to use NaN as a hash key, the
current behavior seems to be "correct".

                        matz.

=end

#3 Updated by Heesob Park almost 6 years ago

=begin
In order to prevent confusion in using NaN as hash key,
it would be better to raise an error like in Lua.

Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio

h = {}
h[0/0.0] = 1
stdin:1: table index is NaN
stack traceback:
stdin:1: in main chunk
[C]: ?

=end

#4 Updated by Shyouhei Urabe almost 6 years ago

=begin
Yukihiro Matsumoto wrote:

Hi,

In message "Re: Re: [Bug #1363] Wrong value for Hash of NaN"
on Mon, 11 May 2009 19:03:59 +0900, Nobuyoshi Nakada nobu@ruby-lang.org writes:

|At Wed, 8 Apr 2009 14:38:31 +0900,
|Heesob Park wrote in :
|> Ruby cannot handle NaN as a unique key of Hash.
|
|It's easy to make them unique as key, I'm not sure which is
|"correct" behavior though.

Two NaN values are not equal with each other by definition, in that
sense, even though some might want to use NaN as a hash key, the
current behavior seems to be "correct".

I don't argue about correctness on NaNs being different each other, but I also
agree with the reporter with Hash being inconvenient when NaNs used as keys.

Attachment: signature.asc
=end

#5 Updated by Yukihiro Matsumoto almost 6 years ago

=begin
Hi,

In message "Re: Re: [Bug #1363] Wrong value for Hash of NaN"
on Mon, 11 May 2009 21:58:42 +0900, Urabe Shyouhei shyouhei@ruby-lang.org writes:

|I don't argue about correctness on NaNs being different each other, but I also
|agree with the reporter with Hash being inconvenient when NaNs used as keys.

Using float values as hash keys should be strongly discouraged,
because you may not have expected result anyway. a 3.14 may be
different in bit-wise representation from another 3.14. I have no
plan to prohibit using them as keys, right now, but see no need to
change the language to encourage bad habit. If I have to make a
change related to this issue, I'd rather prohibit NaN as a key (or
float keys in general), as in .

                        matz.

=end

#6 Updated by Yuki Sonoda over 5 years ago

  • Assignee set to Yukihiro Matsumoto

=begin

=end

#7 Updated by Yusuke Endoh almost 5 years ago

  • Status changed from Open to Rejected
  • Target version set to 2.0.0

=begin
Hi,

The behavior OP reported is not a bug. So I close the ticket.

Indeed, the behavior is confusing a little.
IMO, it would be good to warn when Float is used as hash keys.
Anyway, warning or prohibiting NaN is a new feature, not bug
fix for this ticket. If you still want, please register a
new ticket to Feature tracker.

Thanks,

--
Yusuke Endoh mame@tsg.ne.jp
=end

Also available in: Atom PDF