Why You Should Never Use == to Compare Floats and Doubles in Java

Picture this: you’ve written a piece of Java code that performs some calculations. The logic seems flawless. You have an if statement that checks if two double or float values are equal. But for some reason, the check keeps failing, even when you’re sure the numbers should be identical. What’s going on? Welcome to one of the most common pitfalls in programming: comparing floating-point numbers.

If you’ve ever written code like if (myDouble == 0.3), you might be in for a surprise. Let’s dive into why this is a bad idea and how to do it correctly.

The Hidden Problem with Floating-Point Numbers

The root of the issue lies in how computers store fractional numbers. Both float and double types in Java use a binary representation format (specifically, the IEEE 754 standard). The problem is that just like the fraction 1/3 cannot be perfectly represented as a finite decimal (it’s 0.33333…), many decimal fractions cannot be perfectly represented in binary.

For example, the number 0.1 in decimal is an infinitely repeating fraction in binary. Because the computer has to truncate this at some point, the value it stores is not exactly 0.1, but a very, very close approximation.

When you perform arithmetic with these approximations, the tiny precision errors can add up, leading to unexpected results.

Seeing is Believing: A Code Example

Let’s look at a classic example that trips up many developers. What do you expect the following code to print?

public class FloatComparisonTest {
    public static void main(String[] args) {
        double d1 = 0.1 + 0.2;
        double d2 = 0.3;

        System.out.println("d1 = " + d1);
        System.out.println("d2 = " + d2);

        if (d1 == d2) {
            System.out.println("d1 and d2 are EQUAL");
        } else {
            System.out.println("d1 and d2 are NOT EQUAL");
        }
    }
}

Logically, 0.1 + 0.2 is 0.3, so the program should print that they are equal. But if you run this code, you’ll get this surprising output:

d1 = 0.30000000000000004
d2 = 0.3
d1 and d2 are NOT EQUAL

As you can see, the result of 0.1 + 0.2 is not exactly 0.3 due to those tiny representation errors. The == operator checks for exact equality, bit for bit. Since 0.30000000000000004 is not the same as 0.3, the comparison fails.

The Correct Approach: Comparing with a Tolerance (Epsilon)

So, if we can’t use ==, how should we compare floating-point numbers? The solution is to check if the numbers are “close enough” to each other.

Instead of asking “are these two numbers exactly equal?”, we should ask “is the absolute difference between these two numbers smaller than a tiny, acceptable margin?”. This small margin is often called a tolerance or epsilon.

The formula looks like this:

<code>Math.abs(number1 - number2) < epsilon

The Solution in Action

Let’s fix our previous example using the epsilon-based comparison. We’ll define a small constant for our tolerance.

public class CorrectFloatComparison {
    // A small tolerance for floating point comparisons
    private static final double EPSILON = 0.000001;

    public static void main(String[] args) {
        double d1 = 0.1 + 0.2;
        double d2 = 0.3;

        System.out.println("d1 = " + d1);
        System.out.println("d2 = " + d2);

        if (Math.abs(d1 - d2) < EPSILON) {
            System.out.println("d1 and d2 are considered EQUAL");
        } else {
            System.out.println("d1 and d2 are NOT EQUAL");
        }
    }
}

Now, when you run this code, you get the expected result:

d1 = 0.30000000000000004
d2 = 0.3
d1 and d2 are considered EQUAL

Success! The absolute difference between d1 and d2 is about 0.00000000000000004, which is much smaller than our EPSILON of 0.000001, so our logic correctly identifies them as being equal for all practical purposes.

What about Double.compare() and Float.compare()?

You might be tempted to use the built-in methods like Double.compare(d1, d2). While useful, these methods are not the solution to this specific problem.

According to the Java documentation, Double.compare() behaves similarly to the relational operators. It returns 0 only if the bits are exactly the same. Therefore, Double.compare(0.1 + 0.2, 0.3) will not return 0. These methods are primarily designed for sorting, as they correctly handle NaN and infinity values, but they don’t solve the precision issue for equality checks.

A Reusable Helper Function

Since you’ll likely need to perform this comparison in multiple places, it’s a great idea to create a reusable helper function. You can add this to a utility class in your project.

public class MathUtils {

    private static final double DEFAULT_EPSILON = 0.000001;

    /**
     * Compares two double values to see if they are "close enough".
     *
     * @param d1 The first double.
     * @param d2 The second double.
     * @param epsilon The tolerance for the comparison.
     * @return true if the numbers are within the given tolerance, false otherwise.
     */
    public static boolean areEqual(double d1, double d2, double epsilon) {
        return Math.abs(d1 - d2) < epsilon;
    }

    /**
     * Compares two double values using a default tolerance.
     */
    public static boolean areEqual(double d1, double d2) {
        return areEqual(d1, d2, DEFAULT_EPSILON);
    }
    
    // You can create similar methods for float types
    public static boolean areEqual(float f1, float f2, float epsilon) {
        return Math.abs(f1 - f2) < epsilon;
    }
}

Using this utility, your code becomes much cleaner and more readable:

if (MathUtils.areEqual(d1, d2)) {
    System.out.println("They are equal!");
}

Conclusion

It’s a simple rule, but one that will save you from hard-to-find bugs and headaches:

Never use the == operator to compare float or double values for equality.

Always use a tolerance-based comparison (epsilon) to check if the numbers are close enough for your specific needs. By understanding the nature of floating-point arithmetic and adopting this best practice, you’ll write more robust and predictable Java code.

@ankurm