Comparing small double values in Java

Question

Why this assertion fails in Java:

    double eps = 0.00000000000001;
    double ten = 10.0;
    double result = (ten - (ten - eps));
    Assert.assertTrue(result <= eps);

If I remove one zero before digit 1 in eps, the assertion passes. I assume that this is related to the floating point implementation, but I'm not sure exactly how.

Also, if I replace digit 1 with 2 (like 0.00000000000002) the assertion passes as well. In that case, I can even add more zeros before the digit 2, the test will still pass. I tried with Double.MIN_VALUE (4.9E-324) and the assertion also passed.

Can someone, please, explain in more details:

1. Why the assertion passes with eps = 1.0E-13 but not with eps = 1.0E-14
2. Why the assertion passes with eps = Double.MIN_VALUE (4.9E-324) and not with eps = 1.0E-14

EDIT: The assertion also fails when I increase the eps to 1.0E-8: double eps = 0.00000001;

Answer 1

This is because of the organization of the bytes that represents the double type.

As you can see on the image below, it is a 64 bit structure. The bits [b0 .. b51] are 'concatenated' and elevated by the exponent, [b52 .. b62].

And the equation that determines what each combination of bits represents in real value, is:

With this formula, you have that the minimum value is represented by

3ff0 0000 0000 000116   =>  1.0000000000000002

---

For better explanation, see this wiki page Double-precision floating-point format

Answer 2

In the last assertion you're comparing result (1.0658141036401503E-14) and eps (1.0E-14), matimatically that shoud be wrong as espected from the assertion, result in this case is bigger than eps. If you remove one 0 from eps rps become 1.0E-13 that is bigger than 1.0658141036401503E-14 in this case

Answer 3

The problem is that the assertion code is wrong-ish in a sense that it does not take into account the second subtraction ten - (ten - eps).

Let's explain this step by step. Let eps = 0.00000001 (1.0E-8). In this case, 10.0 - eps is 9.99999999. So far, so good. However, 10.0 - 9.99999999 is 0.00000001000000082740371, which is around the expected result of 0.00000001, but just a little bit larger, because floating point arithmetic (usually) gives just good enough approximation. Therefore, for some eps values the final result is very close, but just below the actual result and for some values it is again very close, but just above the actual result.

The code needs to be fixed in order to take into account that the result of the second subtraction is also just an approximation.

One way to do it is to change the assertion to:

Assert.assertTrue(Math.abs(result - eps) <= eps);

In order to understand more on floating point arithmetics, I've found this article quite well written: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

This quote summarize why the errors in floating point arithmetics happen:

There are two reasons why a real number might not be exactly representable as a floating-point number. The most common situation is illustrated by the decimal number 0.1. Although it has a finite decimal representation, in binary it has an infinite repeating representation. Thus when β = 2, the number 0.1 lies strictly between two floating-point numbers and is exactly representable by neither of them.

Answer 4

Try following code:

BigDecimal eps1 = new BigDecimal(eps);
BigDecimal ten1 = new BigDecimal(ten);
BigDecimal result1 = ten1.subtract( ten1.subtract(eps1) );

It should be stable regardless eps