Clojure JIRA

Clojure JIRA http://dev.clojure.org/jira This file is an XML representation of an issue en-us

4.4

649

25-07-2011

[CLJ-738] <= is incorrect when args include Double/NaN http://dev.clojure.org/jira/browse/CLJ-738 Clojure <p>user> (<= 10 Double/NaN 1)<br/> true</p> <p>(on both 1.2 and 1.3 alpha 5). </p> Mac OS X, Java 6 CLJ-738

<= is incorrect when args include Double/NaN

Defect Minor Closed Completed Luke VanderHart Jason Wolfe Mon, 14 Feb 2011 19:07:09 -0600 Fri, 1 Mar 2013 12:47:10 -0600 Fri, 26 Aug 2011 11:35:55 -0500 Release 1.3 Release 1.3 1 4 <p>The source of the issue seems to be incorrect treatment of boxed NaN:</p> <p>user> (<= 1000 (Double. Double/NaN))<br/> true<br/> user> (<= 1000 (double Double/NaN))<br/> false</p> <p>Primitive comparisons use java's primitive operators directly, which always return false for NaN, even when testing equality between two NaNs.</p> <p>In clojure, Number comparisons are all logical variations around calls to Numbers.Ops.lt(Number, Number). So a call to <tt>(<= x y)</tt> is actually a call to <tt>(not (< y x))</tt>, which eventually uses the primitive <tt><</tt> operator. Alas that logical premise doesn't hold when dealing with NaN:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=> (<= 1 Double/NaN) false user=> (not (< Double/NaN 1)) true </pre> </div></div> <p>So the bug is not that boxed NaN is treated incorrectly, but rather:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user> (<= 1000 (Double. Double/NaN)) ; becomes !(NaN < 1000) true user> (<= 1000 (double Double/NaN)) ; becomes (1000 <= NaN) false </pre> </div></div> <p>In the original example, since there are more than two args, the primitive looking args were boxed:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=> (<= 10 Double/NaN 1) ; equivalent to logical-and of the following true user=> (<= 10 (Double. Double/NaN)) ; becomes !(NaN < 10) true user=> (<= (Double. Double/NaN) 1) ; becomes !(1 < NaN) true </pre> </div></div> <p>Note however that java object comparisons for NaNs behave differently: NaN is the largest Double, and NaNs equal each other (see the <a href="http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#compareTo(java.lang.Double)">javadoc</a>).</p> <p>If we make object NaN comparisons always return false, we would need to add the rest of the comparison methods to <tt>Numbers.Ops</tt>. Yet doing so could also make collection sorting algorithms behave oddly, deviating from sorting written in java. Besides, <tt>(= NaN NaN) => false</tt> is annoying.</p> <p>Clojure already throws out the notion of error-free dividing by zero (which for doubles would otherwise result in NaN or Infinity, depending on the dividend). Perhaps we could similarly error on NaNs passed to clojure numeric ops. They seem to be more trouble than they're worth. That said, people smarter than me thought they were useful.</p> <p>Then there's that -0.0 nonsense...</p> <p>On current master, <tt>(<= x y)</tt> seems to be special-cased by the compiler, but when <tt><=</tt> is called dynamically, the bug is still there:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=> (<= 1 Float/NaN) false user=> (let [op <=] (op 1 Float/NaN)) true </pre> </div></div> <p>Since <a href="http://dev.clojure.org/jira/browse/CLJ-354" title="<= and >= comparisons against NaN return true"><del>CLJ-354</del></a> got marked "Completed", perhaps there was an attempt to fix this.</p> <p>Using <tt>let</tt> forces calling <tt><=</tt> as a function rather than inlining <tt>Numbers/lte</tt>, which means the args are treated as objects not primitives, thus the different behaviour as I discussed earlier.</p> <p>Rich, what should the behavior be?</p> <p>My suggestion for the behavior is to follow Java (Java Language Specification §15.20.1) and IEEE 754. The java.sun.com site seems to be down right now, but here's a Google cache link:</p> <p><a href="http://webcache.googleusercontent.com/search?q=cache:http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.20.1">http://webcache.googleusercontent.com/search?q=cache:http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.20.1</a></p> <p>It should work the same as primitive double in all cases</p> <p>Added patches. The problem was that our logic for lte/gte depended on the fact that lte is equivalent to !gt. </p> <p>However, in Java, this assumption is invalid - any comparison involving NaN always yields false.</p> <p>The fix was to adding lte and gte methods to Numbers.Ops directly, rather than implementing everything in terms of lt. This was the only fix I could see that didn't incur the cost of runtime checks for NaN.</p> Global Rank Patch Code and Test