Why does adding 0.1 multiple times remain lossless?

by

The rounding error is not random and the way it is implemented it attempts to minimise the error. This means that sometimes the error is not visible, or there is not error.

For example 0.1 is not exactly 0.1 i.e. new BigDecimal("0.1") < new BigDecimal(0.1) but 0.5 is exactly 1.0/2

This program shows you the true values involved.

BigDecimal _0_1 = new BigDecimal(0.1);
BigDecimal x = _0_1;
for(int i = 1; i <= 10; i ++) {
    System.out.println(i+" x 0.1 is "+x+", as double "+x.doubleValue());
    x = x.add(_0_1);
}

prints

0.1000000000000000055511151231257827021181583404541015625, as double 0.1
0.2000000000000000111022302462515654042363166809082031250, as double 0.2
0.3000000000000000166533453693773481063544750213623046875, as double 0.30000000000000004
0.4000000000000000222044604925031308084726333618164062500, as double 0.4
0.5000000000000000277555756156289135105907917022705078125, as double 0.5
0.6000000000000000333066907387546962127089500427246093750, as double 0.6000000000000001
0.7000000000000000388578058618804789148271083831787109375, as double 0.7000000000000001
0.8000000000000000444089209850062616169452667236328125000, as double 0.8
0.9000000000000000499600361081320443190634250640869140625, as double 0.9
1.0000000000000000555111512312578270211815834045410156250, as double 1.0

Note: that 0.3 is slightly off, but when you get to 0.4 the bits have to shift down one to fit into the 53-bit limit and the error is discarded. Again, an error creeps back in for 0.6 and 0.7 but for 0.8 to 1.0 the error is discarded.

Adding it 5 times should cumulate the error, not cancel it.

The reason there is an error is due to limited precision. i.e 53-bits. This means that as the number uses more bits as it get larger, bits have to be dropped off the end. This causes rounding which in this case is in your favour.
You can get the opposite effect when getting a smaller number e.g. 0.1-0.0999 => 1.0000000000000286E-4
and you see more error than before.

An example of this is why in Java 6 Why does Math.round(0.49999999999999994) return 1 In this case the loss of a bit in calculation results in a big difference to the answer.

More Related Contents:

  1. Retain precision with double in Java
  2. Why converting from float to double changes the value?
  3. Loss of precision – int -> float or double
  4. How to nicely format floating numbers to string without unnecessary decimal 0’s
  5. Double vs. BigDecimal?
  6. Float and double datatype in Java
  7. Convert float to double without losing precision
  8. Why does Math.round(0.49999999999999994) return 1?
  9. Java:Why should we use BigDecimal instead of Double in the real world? [duplicate]
  10. Double calculation producing odd result [duplicate]
  11. How can I handle precision error with float in Java?
  12. What do F and D mean at the end of numeric literals?
  13. What is the inclusive range of float and double in Java?
  14. Java double precision sum trouble
  15. Why can’t we use ‘==’ to compare two float or double numbers [duplicate]
  16. Java: Inaccuracy using double [duplicate]
  17. How many significant digits do floats and doubles have in java?
  18. Double decimal formatting in Java
  19. Moving decimal places over in a double
  20. When should I use the “strictfp” keyword in java?
  21. How can I truncate a double to only two decimal places in Java?
  22. Do any JVM’s JIT compilers generate code that uses vectorized floating point instructions?
  23. Convert double to BigDecimal and set BigDecimal Precision
  24. How do Java runtimes targeting pre-SSE2 processors implement floating-point basic operations?
  25. ArithmeticException thrown during BigDecimal.divide
  26. Why does integer division by zero 1/0 give error but floating point 1/0.0 returns “Inf”?
  27. Convert Double to Binary representation?
  28. Why is comparing floats inconsistent in Java?
  29. How can I convert integer into float in Java?
  30. Modulus with doubles in Java

Leave a Comment