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

[David Cournapeau]

On Thu, Mar 25, 2010 at 9:39 PM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/25/2010 12:22 PM, Nick Coghlan wrote:
>>   "Not a Number" is not a single floating point value. Instead each
>>   instance is a distinct value representing the precise conditions that
>>   created it. Thus, two "NaN" values x and y will compare equal iff they
>>   are the exact same NaN object (i.e. "if isnan(x) then x == y iff
>>   x is y".
>>
>> As stated above, such a change would allow us to restore reflexivity
>> (eliminating a bunch of weirdness) while still honouring the idea of NaN
>> being a set of values rather than a single value.
>
> Sounds good.
>
> But IEEE 754 was created by pretty clever guys and sure they had a
> reason for define things in the way they are. Probably we are missing
> something.

Yes, indeed. I don't claim having a deep understanding myself, but up
to now, everytime I thought something in IEE 754 was weird, it ended
up being for good reasons.

I think the fundamental missing point in this discussion about Nan is
exception handling: a lot of NaN quircky behavior becomes much more
natural once you take into account which operations are invalid under
which condition. Unless I am mistaken, python itself does not support
for FPU exception handling.

For example, the reason why x != x for x Nan is because != (and ==)
are about the only operations where you can have NaN as operands
without risking raising an exception, and support for creating and
detecting NaN in languages have been coming only quite lately (e.g.
C99).

Concerning the lack of rationale: a relatively short reference
concerned about FPU exception and NaN handling is from Kahan himself

http://www.eecs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

David