Double multiplied by 100 and then cast to long is giving wrong value

Solution 1:

None of the answers seem to deal with why 17.32 acted different.

1. Why it occurred

The difference in behaviour you see between 17.32 and 17.33 & 17.31 is due to IEEE-754 Rounding rules.

Rounding rule applied: from, The Java™ Virtual Machine Specification §2.8.1

The rounding operations of the Java virtual machine always use IEEE 754 round to nearest mode. Inexact results are rounded to the nearest representable value, with ties going to the value with a zero least-significant bit. This is the IEEE 754 default mode. The Java virtual machine does not give any means to change the floating-point rounding mode

2. Your case:

Double is: (1 sign-bit + 11 exponent-bits + 52 fraction-bits = 64bits). Internal representation after rounding below:

             1 [63]      11 [62-52]           52 [51-00]
              Sign        Exponent             Fraction

17.31 -->    0 (+)       10000000011 (+4)     1.0001010011110101110000101000111101011100001010001111
17.32 -->    0 (+)       10000000011 (+4)     1.0001010100011110101110000101000111101011100001010010 //rounded up
17.33 -->    0 (+)       10000000011 (+4)     1.0001010101000111101011100001010001111010111000010100

3. Internal representation (Proof):

17.31: (Mantissa comparison)

Actual:   1.00010100111101011100001010001111010111000010100011110...
Internal: 1.0001010011110101110000101000111101011100001010001111

17.32: (Mantissa comparison)

Actual:   1.00010101000111101011100001010001111010111000010100011... 
Internal: 1.0001010100011110101110000101000111101011100001010010    //round-up!

17.33: (Mantissa comparison)

Actual:   1.00010101010001111010111000010100011110101110000101000...
Internal: 1.0001010101000111101011100001010001111010111000010100

4. Conversion back-to-decimal:

17.31 ->  17.309999999999998721023075631819665431976318359375...
17.32 ->  17.32000000000000028421709430404007434844970703125... //(was rounded up)
17.33 ->  17.3299999999999982946974341757595539093017578125...

(IEEE-754 Analysis Tool)

5. Cast to long

EDIT: There is a factor more at play at your multiplication step as @Jeppe Stig Nielsen said. The result of the FP multiplication (Reference) step does its own rounding-towards-nearest. This changes which results are as expected and which aren't, but the reason is still exactly the same as stated above.

Finally, due to the cast (long), truncation occurs, and leaves you with the results you see. (1730, 1732, 1732)

Narrowing Primitive Conversion : The Java™ Language Specification §5.1.3

If the floating-point number is not an infinity, the floating-point value is rounded to an integer value V, rounding toward zero using IEEE 754 round-toward-zero mode

Solution 2:

The double value is represented not as 17.31, but as 17.309999999999999. That's why when you multiply it by 100 you get 1730.99999999999999999. After conversion to Long your double value is truncated towards zero. So you get 1730.

Solution 3:

As has been explained, this is due to very small floating point precision.

This can be resolve via using a Math.round(), command, as follows:

long j=Math.round(i*100);

This will allow the program to compensate for the very small errors which are inherit using floating point calculations, by not using a floor operation, as the default (long) does.

Solution 4:

Cthulhu and svz's answers are correct. If you want to multiply doubles by 100 and avoid floating point rounding errors, you can use Math.round() to round the result to the closest long after each multiplication:

Double i=17.31;
long j=Math.round(i*100);
System.out.println(j);

This will still have floating point error when dealing extremely large (or negative) doubles. The larger the absolute value of a double, the more the difference is between it and the next double that Java can represent. After some point, consecutive doubles are more than an integer apart, and conventional rounding won't be able to smooth out the difference. For the examples you posted, this should work, though.

Solution 5:

It has to do with the internal representation. If you take a look at i*100 in the first case, you'll see that it is 1730.9999999999998. The cast will only remove the part after the point (truncated).