Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Comparing BigDecimals

 
Vilius Normantas
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which is the better way to check if two BigDecimals are equal?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: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:
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would go for the compareTo method because then you're comparing the values.

For what purpose do you need the hashCode?
 
Campbell Ritchie
Sheriff
Posts: 48917
58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More precisely, as Wouter Oet has told you
. . . if (bigD1.compareTo(BigD2) == 0) . . .
 
Vilius Normantas
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 48917
58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 I want to override equals method, so I do: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
Sheriff
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
That's what String does. Well, apart from the resetting to 0, but that's because String is immutable.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic