RetroSearch Browse

Tue Mar 30 09:51:40 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043694.html

> Edward Loper <edloper at gradient.cis.upenn.edu> writes:
> 
>>This means that 'nan' is no longer a well-behaved dictionary key:
>>
>>     >>> x = {float('nan'):0}
>>     >>> x[float('nan')] = 1
>>     >>> print x
>>     {nan: 0, nan: 1}
>>
>>Even worse, we get different behavior if we use the "same copy" of nan:
>>
>>     >>> nan = float('nan')
>>     >>> x = {nan:0}
>>     >>> x[nan] = 1
>>     >>> print x
>>     {nan: 1}
> 
> Gah.  Still, I think this is more a theoretical objection than
> anything else? [...]
> I have at no point claimed that I have given Python 2.4 a coherent
> ieee 754 floating point story.  All I have tried to do is /reduce/ the
> level of surprise knocking around, and I think I've succeeded.  If
> someone (not me!) has the time and energy to do a 'proper job' (and
> I'd expect working out what that means to be the hard part), then you
> have my support and pre-emptive thanks.

Tim Delaney's suggestion [1] seemed pretty reasonable.  In particular:

   - Ensure that NaN is a singleton (like True and False).  I.e., the
     float constructor checks if the float is NaN, and if so returns a
     singleton.

Advantages:
   - We have an easy way to test if a variable is nan: "x is NaN"
   - nan will work "properly" as a dictionary key

The important question is whether this would slow down other operations. 
  As for cmp(), my understanding was that it should just return -1 if 
two unordered objects are not equal.

-Edward

[1] http://aspn.activestate.com/ASPN/Mail/Message/python-dev/2030764

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

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/043694.html below:

[Python-Dev] Re: Rich comparisons