[Python-Dev] Why is nan != nan?

[P.J. Eby]

At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
>But they're not -- they're *signals* for "your calculation has gone 
>screwy and the result you get is garbage", so to speak. You 
>shouldn't even think of a specific NAN as a piece of specific 
>garbage, but merely a label on the *kind* of garbage you've got (the 
>payload): INF-INF is, in some sense, a different kind of error to 
>log(-1). In the same way you might say "INF-INF could be any number 
>at all, therefore we return NAN", you might say "since INF-INF could 
>be anything, there's no reason to think that INF-INF == INF-INF."

So, are you suggesting that maybe the Pythonic thing to do in that 
case would be to cause any operation on a NAN (including perhaps 
comparison) to fail, rather than allowing garbage to silently propagate?

In other words, if NAN is only a signal that you have garbage, is 
there really any reason to keep it as an *object*, instead of simply 
raising an exception?  Then, you could at least identify what 
calculation created the garbage, instead of it percolating up through 
other calculations.

In low-level languages like C or Fortran, it obviously makes sense to 
represent NAN as a value, because there's no other way to represent 
it.  But in a language with exceptions, is there a use case for it 
existing as a value?