Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

"new BigDecimal(13.3D)" results in imprecise "13.3000000000000007105.."?

How is it that Java's BigDecimal can be this painful?

Double d = 13.3D;

BigDecimal bd1 = new BigDecimal(d);
BigDecimal bd2 = new BigDecimal(String.valueOf(d));


System.out.println("RESULT 1: "+bd1.toString());
System.out.println("RESULT 2: "+bd2.toString());

RESULT 1: 13.300000000000000710542735760100185871124267578125
RESULT 2: 13.3

Is there any situation where Result 1 would be desired? I know that Java 1.5 changed the toString() method but was this the intended consequence?

Also I realise that BigDecimal has doubleValue() etc, but the library that I am working with helpfully uses a toString() and I can't change that :-(

Cheers.

like image 944
Damo Avatar asked Jan 20 '09 10:01

Damo


People also ask

Is BigDecimal more precise than double?

I know that BigDecimal is more precise than double and you should use the former for calculations.

What is the limit of BigDecimal?

By default, BigDecimal numbers have “unlimited” precision. In fact, the maximum unscaled value is equal to 2^Integer.

What is the difference between New BigDecimal and BigDecimal valueOf?

valueOf() has the more intuitive behaviour, while new BigDecimal(d) has the more correct one. Try both and see the difference.

What is the default scale of BigDecimal?

A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale.


1 Answers

Well, the API does address this apparent inconsistency in the constructor BigDecimal(double val):

  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.

Moral of the story: The pain seems self-inflicted, just use new BigDecimal(String val) or BigDecimal.valueOf(double val) instead =)

like image 197
Zach Scrivena Avatar answered Nov 15 '22 14:11

Zach Scrivena