[CLJ-1118] inconsistent numeric comparison semantics between BigDecimal and other Numerics Created: 30/Nov/12 Updated: 25/Apr/13 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4, Release 1.5 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Major |
| Reporter: | Arthur Ulfeldt | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Patch: | Code and Test |
| Description |
|
user> clojure-version It's not clear if this is a bug or an enhancement request, Should BigDecimal's be special in comparason to their smaller equivalents? |
| Comments |
| Comment by Arthur Ulfeldt [ 30/Nov/12 1:51 PM ] |
|
I understand that the definition of equality between bigDecimals is dependent on both value and scale as in this case: user> (== 0.000000M 0.0M) 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. |
| Comment by Arthur Ulfeldt [ 30/Nov/12 2:03 PM ] |
|
this could be fixed by calling stripTrailingZeros on bigDecimals before comparing them to Longs or BigInts. (== 2 (double (. 2.0M stripTrailingZeros))) 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. I think a more complete solution is to use BigDecimal's compareTo method, e.g.: (zero? (.compareTo 2.0M (bigdec 2))) |
| Comment by Timothy Baldridge [ 03/Dec/12 11:31 AM ] |
|
It seems we need some more eyes on this issue, can you bring this up on clojure-dev and see what they think? |
| Comment by Andy Fingerhut [ 14/Apr/13 4:03 AM ] |
|
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. 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. They also say that BigDecimal.compareTo() will return 0 for such BigDecimals. I'm not sure if this is the preferred behavior for Clojure, but if it is, this patch should do it. |
| Comment by Andy Fingerhut [ 15/Apr/13 12:18 AM ] |
|
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. |
| Comment by Andy Fingerhut [ 15/Apr/13 9:07 PM ] |
|
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: 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. |