3

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?

pmor
  • 131
  • 3
  • 3
    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. – njuffa Jan 22 '21 at 01:21
  • 1
    It makes code very difficult to read if you use these special relationships. Just is isnan -- it concisely represents the intent. – Wolfgang Bangerth Jan 22 '21 at 04:49
  • 1
    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? – Federico Poloni Jan 22 '21 at 10:14
  • 2
    @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 Jan 22 '21 at 18:17
  • @pmor Did you compile with /fp:strict? – njuffa Jan 22 '21 at 22:00
  • @njuffa Thanks! The /fp:strict solves NAN <= NAN for C, but does not solve nan <= nan for C++. – pmor Jan 27 '21 at 21:17

1 Answers1

4

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

MPIchael
  • 2,935
  • 10
  • 19