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

Glenn Linderman v+python at g.nevcal.com
Thu Mar 25 20:31:28 CET 2010

```On 3/25/2010 8:13 AM, Mark Dickinson wrote:
> 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.
>>>>
>>> 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.
>

It is my understand that even bit-for-bit identical NaN values will
compare unequal according to IEEE 754 rules.

I would have no problem with Python interning each encountered NaN
value, to avoid having bit-for-bit identical NaN values with different
Python IDs, but having them compare equal seems inappropriate.

Glenn
```