Moving decimal places over in a double

by

If you use double or float, you should use rounding or expect to see some rounding errors. If you can’t do this, use BigDecimal.

The problem you have is that 0.1 is not an exact representation, and by performing the calculation twice, you are compounding that error.

However, 100 can be represented accurately, so try:

double x = 1234;
x /= 100;
System.out.println(x);

which prints:

12.34

This works because Double.toString(d) performs a small amount of rounding on your behalf, but it is not much. If you are wondering what it might look like without rounding:

System.out.println(new BigDecimal(0.1));
System.out.println(new BigDecimal(x));

prints:

0.100000000000000005551115123125782702118158340454101562
12.339999999999999857891452847979962825775146484375

In short, rounding is unavoidable for sensible answers in floating point whether you are doing this explicitly or not.

Note: x / 100 and x * 0.01 are not exactly the same when it comes to rounding error. This is because the round error for the first expression depends on the values of x, whereas the 0.01 in the second has a fixed round error.

for(int i=0;i<200;i++) {
    double d1 = (double) i / 100;
    double d2 = i * 0.01;
    if (d1 != d2)
        System.out.println(d1 + " != "+d2);
}

prints

0.35 != 0.35000000000000003
0.41 != 0.41000000000000003
0.47 != 0.47000000000000003
0.57 != 0.5700000000000001
0.69 != 0.6900000000000001
0.7 != 0.7000000000000001
0.82 != 0.8200000000000001
0.83 != 0.8300000000000001
0.94 != 0.9400000000000001
0.95 != 0.9500000000000001
1.13 != 1.1300000000000001
1.14 != 1.1400000000000001
1.15 != 1.1500000000000001
1.38 != 1.3800000000000001
1.39 != 1.3900000000000001
1.4 != 1.4000000000000001
1.63 != 1.6300000000000001
1.64 != 1.6400000000000001
1.65 != 1.6500000000000001
1.66 != 1.6600000000000001
1.88 != 1.8800000000000001
1.89 != 1.8900000000000001
1.9 != 1.9000000000000001
1.91 != 1.9100000000000001

NOTE: This has nothing to do with randomness in your system (or your power supply). This is due to a representation error, which will produce the same outcome every time. The precision of double is limited and in base 2 rather than base 10, so numbers which can be precisely represented in decimal often cann’t be precisely represented in base 2.

More Related Contents:

  1. Double decimal formatting in Java
  2. Java doesn't know how to multiply? What? [duplicate]
  3. Retain precision with double in Java
  4. Double vs. BigDecimal?
  5. Random weighted selection in Java
  6. Float and double datatype in Java
  7. Java String remove all non numeric characters but keep the decimal separator
  8. How can I format a String number to have commas and round?
  9. Why does Math.round(0.49999999999999994) return 1?
  10. How can I convert a byte array into a double and back?
  11. Java:Why should we use BigDecimal instead of Double in the real world? [duplicate]
  12. Converting Decimal to Binary Java
  13. Number of decimal digits in a double [closed]
  14. What do F and D mean at the end of numeric literals?
  15. Is it valid to compare a double with an int in java?
  16. What is the inclusive range of float and double in Java?
  17. Why does adding 0.1 multiple times remain lossless?
  18. Converting double to integer in Java
  19. Java double precision sum trouble
  20. Difference between double and Double in comparison
  21. Loss of precision – int -> float or double
  22. Why can’t we use ‘==’ to compare two float or double numbers [duplicate]
  23. Comparator with double type
  24. How to manipulate arrays. Find the average. Beginner Java
  25. In Java how do you convert a decimal number to base 36?
  26. Convert a number to 2 decimal places in Java
  27. problem formatting fields in a JTable – differences between Integer and Double
  28. Comparing double values for equality in Java.
  29. Java: Inaccuracy using double [duplicate]
  30. BigDecimal from Double incorrect value?

Leave a Comment