why is the Double.parseDouble making 9999999999999999 to 10000000000000000?

Question

why is the Double.parseDouble making 9999999999999999 to 10000000000000000 ? For Example :

Double d =Double.parseDouble("9999999999999999");
String b= new DecimalFormat("#.##").format(d);
System.out.println(b);

IS Printing

10000000000000000

instead it has to show 9999999999999999 or 9999999999999999.00

Any sort of help is greatly appreciated.

floating point arithmetic --- the greatest mystery of computer science since 1985 — subsub, Jan 18 '12 at 09:28

Mysticial · Answer 1 · 2012-01-18T09:23:04.757

16

The number 9999999999999999 is just above the precision limit of double-precision floating-point. In other words, the 53-bit mantissa is not able to hold 9999999999999999.

So the result is that it is rounded to the nearest double-precision value - which is 10000000000000000.

 9999999999999999 = 0x2386f26fc0ffff  // 54 significant bits needed
10000000000000000 = 0x2386f26fc10000  // 38 significant bits needed

edited Jan 18 '12 at 09:23

answered Jan 18 '12 at 09:17

Mysticial

464,885
45
335
332

+1: Precisely this. It takes _54_ bits to represent an unsigned 9999999999999999 and the largest value that will fit exactly in a standard double is 9007199254740991. – Donal Fellows Jan 18 '12 at 09:20
@DonalFellows Wouldn't it be an even number? If 9007199254740991 can be represented 9007199254740992 must be represented as well. – Peter Lawrey Jan 18 '12 at 09:28
@Peter: 0x1fffffffffffff is an odd number that requires a minimum of 53 bits to represent. The number one larger requires 54 bits (or an exponent). Guess what that value is in decimal? :-) – Donal Fellows Jan 18 '12 at 10:13
3

Technically, you can represent any large integer that has no more than 53 significant bits (and does not overflow). So `2^128` is an integer that's representable as a `double`. But `9007199254740991` and `9007199254740992` are the last *consecutive* integers that are representable in double-precision. – Mysticial Jan 18 '12 at 10:16
@DonalFellows, 9007199254740991 + 1 is even so it only need 53-bit as the last bit (which is zero) can be implied. 9007199254740991 + 2 is odd and required 54-bits. – Peter Lawrey Jan 18 '12 at 12:56
@Peter: But it pushes you into a domain where you no longer get exact conversion between double and 64-bit int. There is special treatment in the FP hardware for encoded integers, but that stops being used when the exponent is varied; the information that the number is (probably) integral is lost. – Donal Fellows Jan 18 '12 at 14:45
@DonalFellows I think we agree to a point. You get an exact conversion from `long` to `double` and it will give you the original value for `9007199254740992`. You can argue this is not the only possible `long` which could have been resulted in this `double`. i.e. its ambiguous. – Peter Lawrey Jan 18 '12 at 15:33

Peter Lawrey · Accepted Answer · 2012-01-18T09:33:44.960

double only has 15/16 digits of accuracy and when you give it a number it can't represent (which is most of the time, even 0.1 is not accurate) it takes the closest representable number.

If you want to represent 9999999999999999 exactly, you need to use BigDecimal.

BigDecimal bd = new BigDecimal("9999999999999999");
System.out.println(new DecimalFormat("#.##").format(bd));

prints

9999999999999999

Very few real world problems need this accuracy because you can't measure anything this accurately anyway. i.e. to an error of 1 part per quintillion.

You can find the largest representable integer with

// search all the powers of 2 until  (x + 1) - x != 1
for (long l = 1; l > 0; l <<= 1) {
    double d0 = l;
    double d1 = l + 1;
    if (d1 - d0 != 1) {
        System.out.println("Cannot represent " + (l + 1) + " was " + d1);
        break;
    }
}

prints

Cannot represent 9007199254740993 was 9.007199254740992E15

The largest representable integer is 9007199254740992 as it needs one less bit (as its even)

It's far more helpful to use binary arithmetic when thinking about normal IEEE doubles than it is to use some sort of decimal approximation. — Donal Fellows, Jan 18 '12 at 10:15
9007199254740992 = 20000000000000 (hex) = 100000000000000000000000000000000000000000000000000000 (bin) — Vladimir Zhilyaev, Jan 18 '12 at 11:30

score 5 · Answer 3 · edited May 23 '17 at 11:51

9999999999999999 requires 54 bits of mantissa in order to be represented exactly, and double only has 52. The number is therefore rounded to the nearest number that can be represented using a 52-bit mantissa. This number happens to be 10000000000000000.

The reason 10000000000000000 requires fewer bits is that its binary representation ends in a lot of zeroes, and those zeroes can get represented by increasing the (binary) exponent.

For detailed explanation of a similar problem, see Why is (long)9223372036854665200d giving me 9223372036854665216?

why is the Double.parseDouble making 9999999999999999 to 10000000000000000?

3 Answers3

Linked