Introduction

You do not test whether a floating-point value is NaN with normal equality, because NaN is defined to be unequal to every value, including itself. The correct approach is to use the language’s dedicated NaN-checking function or method, which follows IEEE 754 floating-point rules.

Core Sections

Why x == NaN never works

NaN means “not a number,” and under IEEE 754 rules it is special: it is not equal to any number and it is not equal to another NaN either.

In Java, this means the following comparison is always false:

1public class Main {
2    public static void main(String[] args) {
3        double value = Double.NaN;
4        System.out.println(value == Double.NaN);
5    }
6}

That surprises many developers at first, but it is expected floating-point behavior.

The right Java answer: Double.isNaN()

In Java, the standard and readable solution is Double.isNaN(value).

1public class Main {
2    public static void main(String[] args) {
3        double value = Math.sqrt(-1.0);
4
5        if (Double.isNaN(value)) {
6            System.out.println("value is NaN");
7        }
8    }
9}

This is the idiomatic test in Java code. It states intent clearly and avoids relying on floating-point tricks.

The self-inequality trick exists, but it is not the best style

Because NaN is the only floating-point value that is not equal to itself, this expression works too:

1public class Main {
2    public static void main(String[] args) {
3        double value = Double.NaN;
4        System.out.println(value != value);
5    }
6}

Technically, this identifies NaN. Practically, it is less readable than Double.isNaN(value). It is more of an IEEE-754 fact than a good code style recommendation.

NaN can propagate through calculations

NaN often appears after invalid floating-point operations, and once it enters a calculation, it tends to propagate.

1public class Main {
2    public static void main(String[] args) {
3        double a = 0.0 / 0.0;
4        double b = a + 10.0;
5
6        System.out.println(Double.isNaN(a));
7        System.out.println(Double.isNaN(b));
8    }
9}

That is why NaN handling matters in numeric code, parsing pipelines, analytics, and scientific computation. One bad value can quietly contaminate later results.

Related checks: infinity is different from NaN

Do not confuse NaN with positive or negative infinity. They are all special floating-point values, but they mean different things.

1public class Main {
2    public static void main(String[] args) {
3        double infinite = 1.0 / 0.0;
4        double nan = 0.0 / 0.0;
5
6        System.out.println(Double.isInfinite(infinite));
7        System.out.println(Double.isNaN(nan));
8    }
9}

If your numeric validation logic cares about all non-finite values, you may need both checks.

Other languages follow the same idea with different APIs

The rule is cross-language even though the function name varies.

1import math
2
3x = float("nan")
4print(math.isnan(x))

1#include <math.h>
2#include <stdio.h>
3
4int main(void) {
5    double x = NAN;
6    printf("%d\n", isnan(x));
7    return 0;
8}

So the deeper lesson is not just “which function do I call.” It is “NaN must be checked with a dedicated predicate rather than normal equality.”

Common Pitfalls

• Comparing directly with == Double.NaN always fails because NaN is not equal to anything, including itself.
• Forgetting that NaN propagates through later arithmetic can hide the original source of bad numeric data.
• Confusing NaN with infinity leads to incomplete validation logic when non-finite values must be handled explicitly.
• Using the self-inequality trick in production code reduces readability compared with Double.isNaN().
• Assuming all floating-point problems are precision issues ignores that NaN is a special value-class issue, not just rounding error.

Summary

• Do not test NaN with ordinary equality.
• In Java, use Double.isNaN(value) for a clear and correct check.
• NaN is unique because it is not equal to itself.
• Infinity and NaN are different special floating-point cases.
• When NaN appears, it often propagates, so early detection improves numeric debugging.