为什么BigDecimal("5.50")不等于BigDecimal("5.5")以及如何解决这个问题？

Question

实际上,我找到了可能的解决方案

//returns true
new BigDecimal("5.50").doubleValue() == new BigDecimal("5.5").doubleValue()

当然,它可以通过类似的Math.abs (v1 - v2) < EPS方式进行改进,使比较更加健壮,但问题是这种技术是否可以接受或是否有更好的解决方案？

如果有人知道为什么java设计师决定以这种方式实现BigDecimal的平等,那么阅读它会很有趣.

Answer 1

来自BigDecimal的javadoc

等于

public boolean equals(Object x)

将其BigDecimal与指定Object的相等性进行比较.与compareTo此不同,此方法只考虑两个BigDecimal对象的值和比例相等(因此,当通过此方法进行比较时,2.0不等于2.00).

简单地使用 compareTo() == 0

Answer 2

从 Java 1.5 开始，最简单的比较忽略尾随零的表达式是：

bd1.stripTrailingZeros().equals(bd2.stripTrailingZeros())

Answer 3

使用==比较双打似乎是一个坏主意一般.

你可以在你要比较的数字上调用setScale:

new BigDecimal ("5.50").setScale(2).equals(new BigDecimal("5.5").setScale (2))

你将把比例设置为两者中的较大者:

BigDecimal a1 = new BigDecimal("5.051");
BigDecimal b1 = new BigDecimal("5.05");
// wow, this is awkward in Java
int maxScale = Collections.max(new ArrayList() {{ a1.scale(), b1.scale()}});
System.out.println(
  a1.setScale(maxScale).equals(b1.setScale(maxScale)) 
  ? "are equal" 
  : "are different" );

但是,使用compareTo() == 0是最好的答案.上述方法中其中一个数字的比例增加可能是compareMagnitude方法文档提到的"不必要的通货膨胀",当它说:

/**
 * Version of compareTo that ignores sign.
 */
private int compareMagnitude(BigDecimal val) {
    // Match scales, avoid unnecessary inflation
    long ys = val.intCompact;
    long xs = this.intCompact;

当然,compareTo它已经很容易使用,因为它已经为您实现了.