3
$\begingroup$

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?

$\endgroup$
6
  • 3
    $\begingroup$ 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. $\endgroup$
    – njuffa
    Commented Jan 22, 2021 at 1:21
  • 1
    $\begingroup$ It makes code very difficult to read if you use these special relationships. Just is isnan -- it concisely represents the intent. $\endgroup$ Commented Jan 22, 2021 at 4:49
  • 1
    $\begingroup$ 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? $\endgroup$ Commented Jan 22, 2021 at 10:14
  • 2
    $\begingroup$ @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). $\endgroup$
    – pmor
    Commented Jan 22, 2021 at 18:17
  • $\begingroup$ @pmor Did you compile with /fp:strict? $\endgroup$
    – njuffa
    Commented Jan 22, 2021 at 22:00

1 Answer 1

4
$\begingroup$

Following many of the comments I would also advise to use the isnan() function wherever possible.

That being said, there -might- be performance differences. It will only ever be reasonable to consider these if you absolutely have to do the NaN checks in the hot loops of your software and can not move them to a less critical position. Also it should be properly tested and documented.

Please also see:

is-isnan-as-fast-as-testing-equality

Where they posted a godbolt (compiler-explorer) link to inspect the assembly code:

godbolt

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.