# How frequently scientific code uses comparisons NaN == NaN?

How frequently scientific code uses comparisons NaN == NaN?

Reason of asking: from time to time compilers / software floating-point library implementations have bugs w.r.t. comparisons with NaN. For instance, NaN == NaN incorrectly returns true, which is a bug.

The end user may face with this bug if the end user relies on the following logic: a != a iff (if and only if) a is NaN. Or inverse version: a == a iff a is not NaN.

However, do people really use this logic (a != a iff a is NaN) in real code? Do people use NaN == NaN comparisons in real code?

Any experience / examples are welcome!

P.S. What is the best stackexchange site to ask this question?

• I have never encountered this idiom in real-life code. I use programming languages in the C/C++ family pretty much exclusively, and for the past twenty years, those have provided a math function isnan() to check for NaNs. I don't remember what we used in the late 1980 and 1990s; I seem to recall proprietary precursors to isnan. Commented Jan 22, 2021 at 1:21
• It makes code very difficult to read if you use these special relationships. Just is isnan -- it concisely represents the intent. Commented Jan 22, 2021 at 4:49
• I thought incorrect floating-point implementations were a relic of the 80s, and now everything is implemented correctly already at the processor level, without leaving libraries and compilers the opportunity to shoot themselves in the foot. Do you have recent examples? Maybe it was just a 'smart' developer trying to replace a bunch of floating point comparisons with a memcmp in their application? Commented Jan 22, 2021 at 10:14
• @FedericoPoloni Example. Not exactly for NaN == NaN, but for NaN <= NaN. Using msvc C compiler printf("%d\n", NAN <= NAN); prints 1 (instead of 0) and using msvc C++ compiler const double nan { std::numeric_limits<double>::quiet_NaN() }; printf("%d\n", nan <= nan); prints 1 (instead of 0).
– pmor
Commented Jan 22, 2021 at 18:17
• @pmor Did you compile with /fp:strict? Commented Jan 22, 2021 at 22:00