http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-1118 Clojure <p>user&gt; <b>clojure-version</b><br/> {:major 1, :minor 5, :incremental 0, :qualifier "beta1"}<br/> user&gt; (== 2.0 2.0M)<br/> true<br/> user&gt; (== 2 2.0M)<br/> false &lt;-- this one is not like the others<br/> user&gt; (== 2 2.0)<br/> true<br/> user&gt; (== 2N 2.0)<br/> true<br/> user&gt; (== 2 (double 2.0M))<br/> true</p> <p>It's not clear if this is a bug or an enhancement request, Should BigDecimal's be special in comparason to their smaller equivalents?</p> CLJ-1118

inconsistent numeric comparison semantics between BigDecimal and other Numerics

Defect Major Open Unresolved Unassigned Arthur Ulfeldt Fri, 30 Nov 2012 13:36:57 -0600 Thu, 25 Apr 2013 19:58:50 -0500 Release 1.4 Release 1.5 0 0 <p>I understand that the definition of equality between bigDecimals is dependent on both value and scale as in this case:</p> <p>user&gt; (== 0.000000M 0.0M)<br/> false</p> <p>I just want to make sure the decission to propagate that semantic across types is intentional. If this is on purpose than this is not a bug.</p> <p>this could be fixed by calling stripTrailingZeros on bigDecimals before comparing them to Longs or BigInts. </p> <p>(== 2 (double (. 2.0M stripTrailingZeros)))<br/> true</p> <p>Edited by Andy Fingerhut: Unfortunately that fails for BigDecimal values equal to 0, unless they happen to have a scale that matches what you are comparing it to.</p> <p>I think a more complete solution is to use BigDecimal's compareTo method, e.g.:</p> <p>(zero? (.compareTo 2.0M (bigdec 2)))<br/> true</p> <p>It seems we need some more eyes on this issue, can you bring this up on clojure-dev and see what they think?</p> <p>Patch clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v1.txt dated Apr 14 2013 changes equiv for BigDecimals so that instead of using BigDecimal.equals(), it uses BigDecimal.compareTo() and checks the return value is equal to 0.</p> <p>The Java docs for these methods explicitly state that BigDecimal.equals() will treat values that are otherwise equal numerically, but differ in scale, as not equal.</p> <p>They also say that BigDecimal.compareTo() will return 0 for such BigDecimals.</p> <p>I'm not sure if this is the preferred behavior for Clojure, but if it is, this patch should do it.</p> <p>clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v2.txt dated Apr 14 2013 is same as clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v1.txt described in previous comment, except it also has some new tests included.</p> <p>clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v3.txt dated Apr 15 2013 is the same as the the previous patch clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v2.txt, except for the following:</p> <p>By changing == behavior for BigDecimal by modifying the BigDecimalOps.equiv() method, that also changes the behavior of = when comparing BigDecimal values to other numbers. hash should be consistent with =, so now hash should return same value for all numerically equal BigDecimal values. This patch should achieve that.</p> Global Rank Patch Code and Test