aspose file tools*
The moose likes Java in General and the fly likes Comparing BigDecimals Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Comparing BigDecimals" Watch "Comparing BigDecimals" New topic
Author

Comparing BigDecimals

Vilius Normantas
Greenhorn

Joined: Jan 18, 2010
Posts: 4
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

Joined: Oct 25, 2008
Posts: 2700

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

For what purpose do you need the hashCode?


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39828
    
  28
More precisely, as Wouter Oet has told you
. . . if (bigD1.compareTo(BigD2) == 0) . . .
Vilius Normantas
Greenhorn

Joined: Jan 18, 2010
Posts: 4
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

Joined: Oct 13, 2005
Posts: 39828
    
  28
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

Joined: Jan 18, 2010
Posts: 4
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

Joined: Oct 27, 2005
Posts: 19760
    
  20

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


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Vilius Normantas
Greenhorn

Joined: Jan 18, 2010
Posts: 4
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

Joined: Oct 27, 2005
Posts: 19760
    
  20

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.
 
Don't get me started about those stupid light bulbs.
 
subject: Comparing BigDecimals