NaNs Just Don't Get No Respect

http://www.drdobbs.com/article/print?articleId=240005723&siteSectionName=cpp

by stianan • 14 years ago

40 35 14 years ago

tzs• 14 years ago

URL for people without bionic eyes: http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240...

tikhonj4• 14 years ago

NaNs are annoying because, thanks to them, equality on floating point numbers is not an equivalence relation. In particular, NaN /= NaN.

This means that in Haskell, for example, you cannot really rely on the Eq class representing an equivalence relation. Code relying on the fact that x == x should be true for all x could not work as expected for floating point numbers.

I don't know if this has any practical ramifications in real code, but it certainly makes things less elegant and more complex than they have to be.

adamzochowski• 14 years ago

This looks very much like NULLs in the SQL world.

A null (and NaN) is like an unknown. One can't compare unknowns because they are exactly that, unknown.

Let's construct a language that on division on zero returns unknowns.

   a =  5 / 0;
   b = 10 / 0;

Now, both a and b are set to unknown state. If one were to compare a to b, should the expectation be that they hold same value?

I wish all languages would have nullability like SQL does. Where a great care has to be given to deal with nullable data, lest nulls nullify everything.

malkia5• 14 years ago

In some languages, a, b would be +Infinity. On top of my head I can't remember whether +Infity != +Infinity (have to write a test and see). For NaN's definitely.

Evbn2• 14 years ago

Would you prefer NaN be another type, like Maybe? And have to all math in a monad or with chronically repeated case analysis?It's necessary complexity, whichever way you do it.

tikhonj4• 14 years ago

Oh, I don't really have a good solution in mind--it's just annoying.

I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.

joshAg5• 14 years ago

Attmepting to just use simple equivalence with any floating point type a horrible idea to begin with, even without NaNs. You should instead declare equivalence if the absolute difference between the two numbers is less than some bound based on what you're doing and not look for bit equivalency.

However, you should be able to examine two NaNs and declare them "equivalent" (for certain definitions of equivalence) by intelligently examining the bits based on the hardware that you're running the program on. In the case of a binary Nan [1] that would entail checking that the exponential fields are both entirely high (eg 0x8 == (a.exponent & b.exponent), assuming a standard 8 bit exponent) and that the mantissas are nonzero (eg a.mantissa && b.mantissa).

[1]: "Binary format NaNs are represented with the exponential field filled with ones (like infinity values), and some non-zero number in the significand (to make them distinct from infinity values)." --http://en.wikipedia.org/wiki/NaN

shrughes6• 14 years ago

That's not true, there are plenty of cases where using equivalence is just fine. Integer arithmetic, and algorithms that are more reliably written not to contain any empty intervals are two examples.

klodolph• 14 years ago

I've gotten a bit pissed at the Microsoft C compiler for (1) having no standard way to generate NaN or Infinity and (2) having a good enough static analyzer that if you generate one by casting, it emits a warning saying that your arithmetic overflows.

Gee, thanks MSC. I didn't expect "x = INFINITY;" to overflow.

malkia5• 14 years ago

0/0 should be NaN, 1/0 should be +Infinity, -1/0 should be -Infinity. (I haven't tried that in a while).

Also check the flags, like /fp:precise for MSVC

roryokane• 14 years ago

An alternative workaround to writing `float f = 0` in languages without NaN:

    float f;
    bool thingIsFoo = condition1; // store the result…
    if (thingIsFoo)
        f = 7;
    // ... code ...
    if (thingIsFoo && condition2) // and explicitly depend on it later
        ++f;

But this causes an extra `&&` to be computed at runtime, so it seems NaNs are still better for this case.

mieubrisse• 14 years ago

You've written quite the interesting and informative article, and your logic as for why you initialize to NaN was perfectly clear.

malkia5• 14 years ago

Be afraid of QNaN the Barbarian!

malkia5• 14 years ago

There are much worse thing than NaN's.

They are called denormals. These appear when dealing at the same time with lots of big numbers (very far away from 0) in operations with lots small numbers (close to 0).

In such cases the FPU (or whatever deals with fp numbers), switches to a format that could be very inefficient producing an order of magnitude slower operations.

For example when dealing with IIR filters in audio, your audio buffer might contain them. One of the solution is to have a white noise buffer somewhere (or couple of numbers) that are not denormalized and add with them - it would magically normalize again.

I'm not a guy dealing with "numerical stability" (usually these are physics, audio or any simualation engine programmers), but know this from simple experience.

zurn• 14 years ago

Denormals are part of IEEE fp. If your implementation is too slow, you can often trade correctness for speed by turning them off in the C/C++ runtimes.

They're also a sign you're skirting on the limits of FP precision (or worse) so a bit of numerical analysis might still be a good idea...

malkia5• 14 years ago

You cannot simply turned them off everywhere. On certain platforms they are produced always, and nothing can be done, but openly deal with them (by expecting them to happen).

voyou• 14 years ago

Stop trying to make D happen. It's not going to happen.

saurik• 14 years ago

The things this author likes about NaN are also properties of NULL in many environments (that NULL cannot be compared to NULL, that operating on NULL returns NULL, etc.); so while you might not see many languages default initializing things to NaN, you do see them default initializing things to NULL with similar effect.

duaneb• 14 years ago

Except this is actually worse, since there are many possible values which evaluate to NaN.

EDIT: I do not know how D implements NaNs; they may have magic to make them more sane to work with.

WalterBright• 14 years ago

D does not implement NaNs, it just relies on the IEEE FP hardware to do it.

What D does do is expose NaNs so the programmer can rely on their existence and use them in a straightforward manner.

NaNs Just Don't Get No Respect

Related Stories