Project

General

Profile

Actions

Bug #1363

closed

Wrong value for Hash of NaN

Added by phasis68 (Heesob Park) almost 15 years ago. Updated almost 13 years ago.

Status:
Rejected
Target version:
ruby -v:
ruby 1.9.1p0 (2009-01-30 revision 21907) [i686-linux]
Backport:
[ruby-core:23154]

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

Actions #1

Updated by nobu (Nobuyoshi Nakada) almost 15 years ago

=begin
Hi,

At Wed, 8 Apr 2009 14:38:31 +0900,
Heesob Park wrote in [ruby-core:23154]:

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

Actions #2

Updated by matz (Yukihiro Matsumoto) almost 15 years ago

=begin
Hi,

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

|At Wed, 8 Apr 2009 14:38:31 +0900,
|Heesob Park wrote in [ruby-core:23154]:
|> 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

Actions #3

Updated by phasis68 (Heesob Park) almost 15 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

Actions #4

Updated by shyouhei (Shyouhei Urabe) almost 15 years ago

=begin
Yukihiro Matsumoto wrote:

Hi,

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

|At Wed, 8 Apr 2009 14:38:31 +0900,
|Heesob Park wrote in [ruby-core:23154]:
|> 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

Actions #5

Updated by matz (Yukihiro Matsumoto) almost 15 years ago

=begin
Hi,

In message "Re: [ruby-core:23427] Re: [Bug #1363] Wrong value for Hash of NaN"
on Mon, 11 May 2009 21:58:42 +0900, Urabe Shyouhei 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 [ruby-core:23426].

						matz.

=end

Actions #6

Updated by yugui (Yuki Sonoda) over 14 years ago

  • Assignee set to matz (Yukihiro Matsumoto)

=begin

=end

Actions #7

Updated by mame (Yusuke Endoh) almost 14 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
=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0