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

[Mark Dickinson]

On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mark Dickinson wrote:
>> On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> Jesus Cea wrote:
>>>> 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, this is where their "implementable in a hardware circuit" focus
>>> comes in. They were primarily thinking of a floating point
>>> representation where the 32/64 bits are *it* - you can't have "multiple
>>> NaNs" because you don't have the bits available to describe them.
>>
>> I'm not so sure about this:  standard 64-bit binary IEEE 754 doubles
>> allow for 2**53-2 different nans (2**52-2 signaling nans, 2**52 quiet
>> nans):  anything with bit pattern (msb to lsb)
>>
>> x1111111 1111xxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
>>
>> is an infinity or a nan, and there are only 2 infinities.
>
> I stand corrected :)
>
> It still seems to me that the problems mostly arise when we're trying to
> get floats and Decimals to behave like Python *objects* (i.e. with
> reflexive equality) rather than like IEEE defined numbers.
>
> It's an extra element that isn't part of the problem the numeric
> standards are trying to solve.

Agreed.  We don't have to be "missing something";  rather, the IEEE
folks (quite understandably) almost certainly didn't anticipate this
kind of usage.  So I'll concede that it's reasonable to consider
deviating from the standard in the light of this.

Mark