new BigDecimal(double) vs new BigDecimal(String) [duplicate]

Answer 1

When you define a double variable in any way, in most cases it won't be the value you have defined, but the closest possible binary representation. You are passing a double to the constructor, so already providing that small imprecision.

Answer 2

Yes, this is floating point error. The problem is that the literals 0.333333333 and 0.666666666 are represented as doubles before being passed as an argument to BigDecimal --- notably, BigDecimal's constructor takes a double as an argument.

This is supported by the standard, which says that floating point literals default to double unless otherwise specified.

Answer 3

Java docs has its answer. According to Java docs of BigDecimal(double val)

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.

Answer 4

Am I wrong in saying that this is because of double imprecision?

You are absolutely right, this is exactly because of double's imprecision.

But since this is a BigDecimal, shouldn't it be the same?

No, it shouldn't. The error is introduced the moment you create new BigDecimal(0.333333333), because 0.333333333 constant already has an error embedded in it. At that point there is nothing you can do to fix this representation error: the proverbial horse is out of the barn by then, so it's too late to close the doors.

When you pass a String, on the other hand, the decimal representation matches the string exactly, so you get a different result.