[Python-Dev] Why is nan != nan?
P.J. Eby
pje at telecommunity.com
Fri Mar 26 02:19:06 CET 2010
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?
More information about the Python-Dev
mailing list