Comparing BigDecimals

[Vilius Normantas]

Which is the better way to check if two BigDecimals are equal?

BigDecimal a = new BigDecimal("8");
BigDecimal b = new BigDecimal("8.00");

// Method 1.
boolean m1 = a.compareTo(b) == 0;
// Method 2.
boolean m2 = a.stripTrailingZeros().equals(b.stripTrailingZeros());

// WRONG way. This doesn't work, as a and b have different scales.
boolean m1 = a.equals(b);

Both methods 1 and 2 seem to work fine. And both are completely unreadable and ugly. Yet which one is better?

Another problem is with hash codes. If I try to do it like this:

BigDecimal a = new BigDecimal("8");
BigDecimal b = new BigDecimal("8.00");

boolean m = a.hashCode() == b.hashCode();

I get m == false. Because a and b have different scales, they also produce different hash code. Can you offer me a good way to get equal hash codes for a and b? This seems to work, but I'm not sure:

a.stripTrailingZeros().hashCode() == b.stripTrailingZeros().hashCode()

[Wouter Oet]

I would go for the compareTo method because then you're comparing the values.

For what purpose do you need the hashCode?

[Campbell Ritchie]

More precisely, as Wouter Oet has told you
. . . if (bigD1.compareTo(BigD2) == 0) . . .

[Vilius Normantas]

Wouter Oet wrote:For what purpose do you need the hashCode?

Generally to generate other hash codes.

Thanks for incredibly fast reply
Is something wrong with "a.stripTrailingZeros().equals(b.stripTrailingZeros())", or you just don't like it for readability/performance/style/etc. reasons?

[Campbell Ritchie]

The stripTrailingZeroes method creates a new object, so might have a performance overhead against compareTo.

At which point this ceases to be "beginning" material and needs to move to another forum.

[Vilius Normantas]

Campbell Ritchie wrote:The stripTrailingZeroes method creates a new object, so might have a performance overhead against compareTo.

At which point this ceases to be "beginning" material and needs to move to another forum.

Thank you.

What about hash codes? Does it make sense to use stripTrailingZeroes when I want equal hash codes for BigDecimals with the same value but different scales?

[Rob Spoor]

Equal hash codes does not necessarily mean equal objects. Keep that in mind. I wouldn't ever use hash code comparison for equality tests.

[Vilius Normantas]

Rob Prime wrote:Equal hash codes does not necessarily mean equal objects. Keep that in mind. I wouldn't ever use hash code comparison for equality tests.

Neither would I.

My problem is this. Let's say I have a class MyClass which among other fields includes

private BigDecimal a;

I want to override equals method, so I do:

@Override
public boolean equals(Object obj)
{
   if (this == obj)
   {
      return true;
   }
   if (obj == null || !getClass().equals(obj.getClass()))
   {
      return false;
   }
   return 
      // Compare other fields ... &&
      a.compareTo(((MyClass)obj).a) == 0;
}

As far as I know, it's a good practice to override hashCode() together with equals. So I need a way to get hashCode of the "BigDecimal a" field in such way that it doesn't depend on BigDecimal's scale (so that my hashCode is compatible with my equals which doesn't use scale of the BigDecimals). If I just used a.hashCode(), there could be a case when to objects are equal, but have different hashCodes (due to the scale of BigDecimal).

[Rob Spoor]

In that case using stripZeros may be the best solution. If you are concerned about memory usage you can choose to cache the hash code:

private transient int hash = 0;

public int hashCode()
{
    if (hash == 0)
    {
        // calculate and assign
    }
    return hash;
}

public void setSomeField(SomeType x)
{
    this.x = x;
    // only if the hash code is using this.x
    hash = 0;
}

That's what String does. Well, apart from the resetting to 0, but that's because String is immutable.