RetroSearch Browse

Mon Mar 29 09:21:01 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043671.html

Edward Loper <edloper at gradient.cis.upenn.edu> writes:

> Michael Hudson wrote:
>>  >>> float('nan')
>>  nan
>>  >>> _ == _
>>  False
>
> 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?

BTW, with 2.3 on OS X:

>>> {1e3000/1e3000:1}[0]
1
>>> {0:2}[1e3000/1e3000]
2

So your 'no longer' isn't really valid :-)

> If we *really* want nan==nan to be false, then it seems like we have
> to say that nan is unhashable.  I'm also disturbed by the fact that
> cmp() has something different to say about their equality:
>
>      >>> cmp(float('nan'), float('nan'))
>      0

Well, yah.  cmp() assumes a total ordering.  If there just isn't one,
what can we do?

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.

Cheers,
mwh

-- 
  MARVIN:  Oh dear, I think you'll find reality's on the blink again.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 12

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

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

[Python-Dev] Rich comparisons