NaNs are annoying because, thanks to them, equality on floating point numbers is not an equivalence relation. In particular, NaN /= NaN.<p>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.<p>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.
There are much worse thing than NaN's.<p>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).<p>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.<p>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.<p>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.
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.
An alternative workaround to writing `float f = 0` in languages without NaN:<p><pre><code> float f;
bool thingIsFoo = condition1; // store the result…
if (thingIsFoo)
f = 7;
// ... code ...
if (thingIsFoo && condition2) // and explicitly depend on it later
++f;
</code></pre>
But this causes an extra `&&` to be computed at runtime, so it seems NaNs are still better for this case.
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.<p>Gee, thanks MSC. I didn't expect "x = INFINITY;" to overflow.
URL for people without bionic eyes: <a href="http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723" rel="nofollow">http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240...</a>