BigDecimal compareTo not working as expected

Question

According to the JavaDoc for BigDecimal, the compareTo function does not account for the scale during comparison.

Now I have a test case th

Answer 1

new BigDecimal(0.7) does not represent 0.7.

It represents 0.6999999999999999555910790149937383830547332763671875 (exactly).

The reason for this is that the double literal 0.7 doesn't represent 0.7 exactly.

If you need precise BigDecimal values, you must use the String constructor (actually all constructors that don't take double values will work).

Try new BigDecimal("0.7") instead.

The JavaDoc of the BigDecimal(double) constructor has some related notes:

1. The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.

2. The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates a BigDecimal which is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the String constructor be used in preference to this one.

3. When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the same result as converting the double to a String using the Double.toString(double) method and then using the BigDecimal(String) constructor. To get that result, use the static valueOf(double) method.

So to summarize: If you want to create a BigDecimal with a fixed decimal value, use the String constructor. If you already have a double value, then BigDecimal.valueOf(double) will provide a more intuitive behaviour than using new BigDecimal(double).