We're updating the issue view to help you get more done. 

inconsistent numeric comparison semantics between BigDecimal and other Numerics

Description

BigDecimal does not have consistent comparison semantics with other numeric types.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 user> *clojure-version* {:major 1, :minor 5, :incremental 1, :qualifier nil} user> (== 2.0 2.0M) true user> (== 2 2.0M) false <-- this one is not like the others user> (== 2 2.0) true user> (== 2N 2.0) true user> (== 2 (double 2.0M)) true user> (== 1.0M 1.00M) false ;; potentially surprising

Patch: clj-1118-v7.patch

Approach: Change equiv for BigDecimals so that instead of using BigDecimal.equals(), it uses BigDecimal.compareTo() and checks the return value is equal to 0.

The javadoc for these methods explicitly states 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.

Doing this also changes the behavior of = when comparing BigDecimal values to other numbers. hash should be consistent with =, so now hash should return the same value for all numerically equal BigDecimal values. This patch modifies hasheq() to return the same value for all numerically equal BigDecimal values, by calling BigDecimal.stripTrailingZeros() on them before hashing. This change also will make 1.0M == 1.00M which was not true before.

Screened by: Alex Miller

Environment

None

Status

Assignee

Unassigned

Reporter

import

Labels

Approval

Ok

Patch

Code and Test

Fix versions

Affects versions

Release 1.5
Release 1.4

Priority

Major