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

David Cournapeau cournape at gmail.com
Fri Mar 26 18:04:06 CET 2010


On Fri, Mar 26, 2010 at 10:19 AM, P.J. Eby <pje at telecommunity.com> wrote:
> 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?

Nan behavior being tightly linked to FPU exception handling, I think
this is a good idea. One of the goal of Nan is to avoid many testing
in intermediate computation (for efficiency reason), which may not
really apply to python. Generally, you want to detect
errors/exceptional situations as early as possible, and if you use
python, you don't care about potential slowdown caused by those
checks.

David


More information about the Python-Dev mailing list