RetroSearch Browse

Thu Mar 25 20:31:28 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-March/098913.html

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.
>>>>          
>>> 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.
>    

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098913.html below:

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