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

Question

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.

Actually the toString() version is probably what you want. Decimal numbers cannot be properly represented as a double, and while BigDecimals solve this problem, giving them a double in the constructor undermines the solution as they do not have an accurate number to start from. — Andrzej Doyle, Jan 20 '09 at 11:04

Zach Scrivena · Accepted Answer · 2009-01-20T11:03:40.917

Well, the API does address this apparent inconsistency in the constructor 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 (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.

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.

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 =)

+1: That's how Double really works. Not much to do with BigDecimal. — S.Lott, Jan 20 '09 at 11:03
Note that also new BigDecimal(d+"") works fine. Results in "13.3" just like when using valueOf(d) — BAERUS, May 28 '15 at 12:27

score 11 · Answer 2 · edited Dec 14 '11 at 21:23

11

Your problem has nothing to do with BigDecimal, and everything with Double, which cannot represent 13.3 accurately, since it uses binary fractions internally.

So your error is introduced in the very first line. The first BigDecimal simply preserves it, while String.valueOf() does some fishy rounding that causes the second one to have the desired content, pretty much through luck.

edited Dec 14 '11 at 21:23

Bhesh Gurung

50,430
22
93
142

answered Jan 20 '09 at 10:40

Michael Borgwardt

342,105
78
482
720

score 8 · Answer 3 · answered Jan 20 '09 at 10:39

8

You might want to inform yourself about how floating-point values are implemented (IEEE 754-1985). And suddenly, everything will become crystal-clear.

answered Jan 20 '09 at 10:39

Bombe

81,643
20
123
127

score 5 · Answer 4 · edited Dec 14 '11 at 21:24

5

This isn't the fault of BigDecimal - it's the fault of double. BigDecimal is accurately representing the exact value of d. String.valueOf is only showing the result to a few decimal places.

edited Dec 14 '11 at 21:24

Bhesh Gurung

50,430
22
93
142

answered Jan 20 '09 at 10:38

Jon Skeet

1,421,763
867
9,128
9,194

score 3 · Answer 5 · edited Dec 14 '11 at 21:24

Fractions represented with binary number types(i.e. double, float) cannot be accurately stored in those types.

    Double d = 13.3;        
    BigDecimal bdNotOk = new BigDecimal(d);
    System.out.println("not ok: " + bdNotOk.toString());

    BigDecimal bdNotOk2 = new BigDecimal(13.3);
    System.out.println("not ok2: " + bdNotOk2.toString());

    double x = 13.3;
    BigDecimal ok = BigDecimal.valueOf(x);
    System.out.println("ok: " + ok.toString());

    double y = 13.3;
    // pretty lame, constructor's behavior is different from valueOf static method
    BigDecimal bdNotOk3 = new BigDecimal(y);
    System.out.println("not ok3: " + bdNotOk3.toString());

    BigDecimal ok2 = new BigDecimal("13.3");
    System.out.println("ok2: " + ok2.toString());

    Double e = 0.0;
    for(int i = 0; i < 10; ++i) e = e + 0.1; // some fractions cannot be accurately represented with binary
    System.out.println("not ok4: " + e.toString()); // should be 1


    BigDecimal notOk5 = BigDecimal.valueOf(e);
    System.out.println("not ok5: " + notOk5.toString()); // should be 1

    /* 
     * here are some fractions that can be represented exactly in binary:
     * 0.5   = 0.1   = 1 / 2
     * 0.25  = 0.01  = 1 / 4
     * 0.75  = 0.11  = 3 / 4
     * 0.125 = 0.001 = 1 / 8
     */

output:

not ok: 13.300000000000000710542735760100185871124267578125
not ok2: 13.300000000000000710542735760100185871124267578125
ok: 13.3
not ok3: 13.300000000000000710542735760100185871124267578125
ok2: 13.3
not ok4: 0.9999999999999999
not ok5: 0.9999999999999999

Just use BigDecimal.valueOf(d) or new BigDecimal(s).

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

5 Answers5

Linked

Related