Bug #1720

[NaN] == [NaN] が true になる

Added by tadayoshi funaba almost 6 years ago. Updated over 2 years ago.

Status:Closed
Priority:Normal
Assignee:Kenta Murata
ruby -v:ruby 1.9.2dev (2009-07-03 trunk 23945) [i686-linux] Backport:

Description

=begin
NaN = 0.0/0
[NaN] == [NaN] が true になりますが、

NaN == NaN #=> false
[1] == [1.0] #=> true

という結果からするとおかしいように思います。
=end


Related issues

Duplicated by Ruby trunk - Bug #7676: Comparison of Float::NAN in array behaves unexpectedly Open 01/09/2013

Associated revisions

Revision 37546
Added by Kenta Murata over 2 years ago

  • numeric.c: Add description of that the results of the comparing operations of two NaNs are undefined. [#1720]

Revision 37546
Added by Kenta Murata over 2 years ago

  • numeric.c: Add description of that the results of the comparing operations of two NaNs are undefined. [#1720]

History

#1 Updated by Yukihiro Matsumoto almost 6 years ago

=begin
まつもと ゆきひろです

In message "Re: [Bug #1720] [NaN] == [NaN] が true になる"
on Fri, 3 Jul 2009 21:43:24 +0900, tadayoshi funaba redmine@ruby-lang.org writes:

|NaN = 0.0/0
|[NaN] == [NaN] が true になりますが、
|
|NaN == NaN #=> false
|[1] == [1.0] #=> true
|
|という結果からするとおかしいように思います。

確かに。rb_equal()が両辺が同じオブジェクトのときにメソッド呼
び出しを行わずに真を返しているせいですね。NaNというのは、
equal?が成立しても==が成立しないという特異なオブジェクトであ
るためにこの問題が発生しています。

とはいえ、こんな特殊な例のために同値性チェックを遅くしたくな
いし、困ったものです。

=end

#2 Updated by Yukihiro Matsumoto almost 6 years ago

=begin
まつもと ゆきひろです

In message "Re: Re: [Bug #1720] [NaN] == [NaN] が true になる"
on Sun, 5 Jul 2009 01:14:16 +0900, Yukihiro Matsumoto matz@ruby-lang.org writes:

||NaN = 0.0/0
||[NaN] == [NaN] が true になりますが、
||
||NaN == NaN #=> false
||[1] == [1.0] #=> true
||
||という結果からするとおかしいように思います。
|
|確かに。rb_equal()が両辺が同じオブジェクトのときにメソッド呼
|び出しを行わずに真を返しているせいですね。NaNというのは、
|equal?が成立しても==が成立しないという特異なオブジェクトであ
|るためにこの問題が発生しています。

考えられる対処は

(1) NaN == NaN も true にする
一貫性はあるが NaN の本来の挙動ではない
(2) rb_equal()でまずequal?でのチェックをやめる
性能が劣化するので避けたい
(3) rb_equal()でT_FLOATを特別扱い
2ほどではないにしても性能劣化が気になる
特別扱いは後悔することが多い
(4) このまま。これは例外的なケースとする

くらいでしょうか。

私自身は、どれが良いという意見を現時点では持たないのですが、
どれが好きかと言われれば、(1)が好きです。

=end

#3 Updated by tadayoshi funaba almost 6 years ago

=begin
そんなに速度的にきついんですかね。
であれば、あまり妙なことはしないほうがいいと思うので、
既知の問題として当面は(4)とするとか。
=end

#4 Updated by Yuki Sonoda almost 6 years ago

  • Status changed from Open to Assigned
  • Assignee set to Yukihiro Matsumoto
  • Priority changed from Normal to 3

=begin
私も(4)を推します。

NaNが生じるケースって、要は例外を発生すべきところ伝統的なモデルを尊重してこうなっている、と理解していますから。無理に整合性を持たせようとしても難しいんじゃないかなーと。だとすると一番被害が少ないのが(4)だと思います。
=end

#5 Updated by Keiju Ishitsuka almost 6 years ago

=begin
けいじゅ@いしつかです.

In the message: " Re: [Bug #1720]
[NaN] == [NaN] が true になる", on Jul/05 01:31(JST) Yukihiro
Matsumoto writes:

まつもと ゆきひろです

(1) NaN == NaN も true にする
一貫性はあるが NaN の本来の挙動ではない
(2) rb_equal()でまずequal?でのチェックをやめる
性能が劣化するので避けたい
(3) rb_equal()でT_FLOATを特別扱い
2ほどではないにしても性能劣化が気になる
特別扱いは後悔することが多い
(4) このまま。これは例外的なケースとする

私自身は、どれが良いという意見を現時点では持たないのですが、
どれが好きかと言われれば、(1)が好きです。

わたしも, (1)のような気がします.

というか, (1')ですか:

(1')
nan1 = 0.0/0
nan2 = 0.0/0

として,

nan1 == nan1 => true
nan1 == nan2 => false

現行では,

nan1.equal?(nan1)

なのに,

nan1 == nan1 => false

となるのは,オブジェクト指向的にかなり気分の悪い仕様だと思います. nan1
とnan1の値はやはり同じだとしてよいと思います.

 一貫性はあるが NaN の本来の挙動ではない

とありますが, それに関しては nan1 == nan2 => false になれば問題ないき
がします.

__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: keiju@ishitsuka.com <<---

=end

#6 Updated by Koichi Sasada about 4 years ago

誰に聞けばいいのかわかりませんが,これはどうなりますでしょうか.

#7 Updated by Yukihiro Matsumoto almost 3 years ago

  • Status changed from Assigned to Closed

Rubyの言語仕様的にはNaNとNaNの比較は未定義と言うことにします。
処理系によっては等しいかもしれないし、そうでないかもしれない。

#8 Updated by Koichi Sasada almost 3 years ago

  • Category set to doc
  • Status changed from Closed to Assigned
  • Assignee changed from Yukihiro Matsumoto to Kenta Murata

=begin

NaN と NaN の挙動は未定義ということで,実装は変えませんが,
ドキュメントの改訂が必要です.mrkn が引き受けてくれました.

=end

#9 Updated by Kenta Murata over 2 years ago

  • Status changed from Assigned to Closed

Also available in: Atom PDF