https://bugs.ruby-lang.org/
https://bugs.ruby-lang.org/favicon.ico?1711330511
2009-07-05T01:14:28Z
Ruby Issue Tracking System
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=4469
2009-07-05T01:14:28Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul></ul><p>まつもと ゆきひろです</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-dev/38725">[ruby-dev:38725]</a> [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: [NaN] == [NaN] が true になる (Closed)" href="https://bugs.ruby-lang.org/issues/1720">#1720</a>] [NaN] == [NaN] が true になる"<br>
on Fri, 3 Jul 2009 21:43:24 +0900, tadayoshi funaba <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> writes:</p>
<blockquote>
<p><code>NaN = 0.0/0</code><br>
<code>[NaN] == [NaN]</code> が true になりますが、</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="no">NaN</span> <span class="o">==</span> <span class="no">NaN</span> <span class="c1">#=> false</span>
<span class="p">[</span><span class="mi">1</span><span class="p">]</span> <span class="o">==</span> <span class="p">[</span><span class="mf">1.0</span><span class="p">]</span> <span class="c1">#=> true</span>
</code></pre>
<p>という結果からするとおかしいように思います。</p>
</blockquote>
<p>確かに。<code>rb_equal()</code>が両辺が同じオブジェクトのときにメソッド呼<br>
び出しを行わずに真を返しているせいですね。NaNというのは、<br>
<code>equal?</code>が成立しても<code>==</code>が成立しないという特異なオブジェクトであ<br>
るためにこの問題が発生しています。</p>
<p>とはいえ、こんな特殊な例のために同値性チェックを遅くしたくな<br>
いし、困ったものです。</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=4470
2009-07-05T01:31:48Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul></ul><p>まつもと ゆきひろです</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-dev/38734">[ruby-dev:38734]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: [NaN] == [NaN] が true になる (Closed)" href="https://bugs.ruby-lang.org/issues/1720">#1720</a>] [NaN] == [NaN] が true になる"<br>
on Sun, 5 Jul 2009 01:14:16 +0900, Yukihiro Matsumoto <a href="mailto:matz@ruby-lang.org" class="email">matz@ruby-lang.org</a> writes:</p>
<blockquote>
<blockquote>
<p><code>NaN = 0.0/0</code><br>
<code>[NaN] == [NaN]</code> が true になりますが、</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="no">NaN</span> <span class="o">==</span> <span class="no">NaN</span> <span class="c1">#=> false</span>
<span class="p">[</span><span class="mi">1</span><span class="p">]</span> <span class="o">==</span> <span class="p">[</span><span class="mf">1.0</span><span class="p">]</span> <span class="c1">#=> true</span>
</code></pre>
<p>という結果からするとおかしいように思います。</p>
</blockquote>
<p>確かに。<code>rb_equal()</code>が両辺が同じオブジェクトのときにメソッド呼<br>
び出しを行わずに真を返しているせいですね。NaNというのは、<br>
<code>equal?</code>が成立しても<code>==</code>が成立しないという特異なオブジェクトであ<br>
るためにこの問題が発生しています。</p>
</blockquote>
<p>考えられる対処は</p>
<p>(1) <code>NaN == NaN</code> も true にする<br>
一貫性はあるが NaN の本来の挙動ではない<br>
(2) <code>rb_equal()</code>でまず<code>equal?</code>でのチェックをやめる<br>
性能が劣化するので避けたい<br>
(3) <code>rb_equal()</code>で<code>T_FLOAT</code>を特別扱い<br>
2ほどではないにしても性能劣化が気になる<br>
特別扱いは後悔することが多い<br>
(4) このまま。これは例外的なケースとする</p>
<p>くらいでしょうか。</p>
<p>私自身は、どれが良いという意見を現時点では持たないのですが、<br>
どれが好きかと言われれば、(1)が好きです。</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=4480
2009-07-05T18:35:25Z
tadf (tadayoshi funaba)
<ul></ul><p>そんなに速度的にきついんですかね。<br>
であれば、あまり妙なことはしないほうがいいと思うので、<br>
既知の問題として当面は(4)とするとか。</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=4593
2009-07-13T20:53:16Z
yugui (Yuki Sonoda)
yugui@yugui.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>3</i></li></ul><p>私も(4)を推します。</p>
<p>NaNが生じるケースって、要は例外を発生すべきところ伝統的なモデルを尊重してこうなっている、と理解していますから。無理に整合性を持たせようとしても難しいんじゃないかなーと。だとすると一番被害が少ないのが(4)だと思います。</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=4599
2009-07-13T21:14:16Z
keiju (Keiju Ishitsuka)
keiju@ishitsuka.com
<ul></ul><p>けいじゅ@いしつかです.</p>
<p>In <a href="https://blade.ruby-lang.org/ruby-dev/38735">[ruby-dev:38735]</a> the message: "<a href="https://blade.ruby-lang.org/ruby-dev/38735">[ruby-dev:38735]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: [NaN] == [NaN] が true になる (Closed)" href="https://bugs.ruby-lang.org/issues/1720">#1720</a>]<br>
[NaN] == [NaN] が true になる", on Jul/05 01:31(JST) Yukihiro<br>
Matsumoto writes:</p>
<blockquote>
<p>まつもと ゆきひろです</p>
</blockquote>
<blockquote>
<p>(1) NaN == NaN も true にする<br>
一貫性はあるが NaN の本来の挙動ではない<br>
(2) rb_equal()でまずequal?でのチェックをやめる<br>
性能が劣化するので避けたい<br>
(3) rb_equal()でT_FLOATを特別扱い<br>
2ほどではないにしても性能劣化が気になる<br>
特別扱いは後悔することが多い<br>
(4) このまま。これは例外的なケースとする</p>
</blockquote>
<blockquote>
<p>私自身は、どれが良いという意見を現時点では持たないのですが、<br>
どれが好きかと言われれば、(1)が好きです。</p>
</blockquote>
<p>わたしも, (1)のような気がします.</p>
<p>というか, (1')ですか:</p>
<p>(1')</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">nan1</span> <span class="o">=</span> <span class="mf">0.0</span><span class="o">/</span><span class="mi">0</span>
<span class="n">nan2</span> <span class="o">=</span> <span class="mf">0.0</span><span class="o">/</span><span class="mi">0</span>
</code></pre>
<p>として,</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">nan1</span> <span class="o">==</span> <span class="n">nan1</span> <span class="o">=></span> <span class="kp">true</span>
<span class="n">nan1</span> <span class="o">==</span> <span class="n">nan2</span> <span class="o">=></span> <span class="kp">false</span>
</code></pre>
<p>現行では,</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">nan1</span><span class="p">.</span><span class="nf">equal?</span><span class="p">(</span><span class="n">nan1</span><span class="p">)</span>
</code></pre>
<p>なのに,</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">nan1</span> <span class="o">==</span> <span class="n">nan1</span> <span class="o">=></span> <span class="kp">false</span>
</code></pre>
<p>となるのは,オブジェクト指向的にかなり気分の悪い仕様だと思います. nan1<br>
とnan1の値はやはり同じだとしてよいと思います.</p>
<blockquote>
<p>一貫性はあるが NaN の本来の挙動ではない</p>
</blockquote>
<p>とありますが, それに関しては <code>nan1 == nan2</code> => <code>false</code> になれば問題ないき<br>
がします.</p>
<p>__<br>
---------------------------------------------------->> 石塚 圭樹 <<---<br>
---------------------------------->> e-mail: <a href="mailto:keiju@ishitsuka.com" class="email">keiju@ishitsuka.com</a> <<---</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=17704
2011-06-11T14:30:28Z
ko1 (Koichi Sasada)
<ul></ul><p>誰に聞けばいいのかわかりませんが,これはどうなりますでしょうか.</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=28021
2012-07-14T14:13:04Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul><p>Rubyの言語仕様的にはNaNとNaNの比較は未定義と言うことにします。<br>
処理系によっては等しいかもしれないし、そうでないかもしれない。</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=28022
2012-07-14T14:15:07Z
ko1 (Koichi Sasada)
<ul><li><strong>Category</strong> set to <i>doc</i></li><li><strong>Status</strong> changed from <i>Closed</i> to <i>Assigned</i></li><li><strong>Assignee</strong> changed from <i>matz (Yukihiro Matsumoto)</i> to <i>mrkn (Kenta Murata)</i></li></ul><p>NaN と NaN の挙動は未定義ということで,実装は変えませんが,<br>
ドキュメントの改訂が必要です.mrkn が引き受けてくれました.</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=32604
2012-11-08T10:18:56Z
mrkn (Kenta Murata)
muraken@gmail.com
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=67636
2017-10-30T20:58:51Z
Eregon (Benoit Daloze)
<ul></ul><p>Could someone summarize in English the rationale?</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="no">Float</span><span class="o">::</span><span class="no">NAN</span> <span class="o">==</span> <span class="no">Float</span><span class="o">::</span><span class="no">NAN</span> <span class="c1"># => false</span>
</code></pre>
<p>The documentation says:</p>
<pre><code>The result of NaN == NaN is undefined, so the implementation-dependent
value is returned.
</code></pre>
<p>But the result is false no matter the environment, isn't it? (NaN is the only numeric value never equal to itself)</p>
<p>And then we have:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[</span><span class="no">Float</span><span class="o">::</span><span class="no">NAN</span><span class="p">]</span> <span class="o">==</span> <span class="p">[</span><span class="no">Float</span><span class="o">::</span><span class="no">NAN</span><span class="p">]</span> <span class="c1"># => true</span>
<span class="p">[</span><span class="mf">0.0</span><span class="o">/</span><span class="mi">0</span><span class="p">]</span> <span class="o">==</span> <span class="p">[</span><span class="no">Float</span><span class="o">::</span><span class="no">NAN</span><span class="p">]</span> <span class="c1"># => false</span>
</code></pre>
<p>Which sounds to me like a bad side effect of short-circuiting in rb_equal on</p>
<pre><code class="c syntaxhl" data-language="c"><span class="k">if</span> <span class="p">(</span><span class="n">a</span> <span class="o">==</span> <span class="n">b</span><span class="p">)</span>
<span class="k">return</span> <span class="n">Qtrue</span><span class="p">;</span>
<span class="k">else</span>
<span class="k">return</span> <span class="nf">rb_funcall</span><span class="p">(</span><span class="n">a</span><span class="p">,</span> <span class="s">"=="</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">b</span><span class="p">);</span>
</code></pre>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=67637
2017-10-30T22:59:26Z
Eregon (Benoit Daloze)
<ul></ul><p>At least IEEE 754 has <code>NaN == NaN # => false</code>.</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=67639
2017-10-31T03:07:52Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul></ul><p>Summary:</p>
<p>ko1: <code>[NaN] == [NaN]</code> evaluates to true. This looks awkward since <code>NaN == NaN</code> is <code>false</code> and <code>[1] == [1.0]</code> is <code>true</code>.</p>
<p>matz: <code>rb_equal</code> first checks if the two sides are the same, which causes this behavior. <code>NaN</code> is a special object since <code>equal?</code> returns true but <code>==</code> returns false. However, I don't want to make equivalence check slow for such a special case. There are some approaches to fix this issue: (1) make <code>NaN == NaN</code>, which is consistent but unnatural, (2) change <code>rb_equal()</code> not to check <code>equal?</code>, which will cause performance degradation, (3) change <code>rb_equal()</code> to handle T_FLOAT specially, which will also cause performance degradation, and (4) do nothing. ... I decide that the comparison of <code>NaN</code> and <code>NaN</code> is undefined in Ruby.</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=67648
2017-10-31T12:23:03Z
Eregon (Benoit Daloze)
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a>: Thank you for the summary, that's very helpful!</p>
Ruby master - Bug #1720: [NaN] == [NaN] が true になる
https://bugs.ruby-lang.org/issues/1720?journal_id=67659
2017-11-01T08:56:18Z
Hanmac (Hans Mackowiak)
hanmac@gmx.de
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a></p>
<p>checkout the object id <code>Float::NAN.object_id != (0.0/0).object_id</code><br>
while <code>NAN</code> is a constant, <code>(0.0/0)</code> returns a new object each time</p>
<p>thats why your Array compare shows a difference</p>