[Python-Dev] Rich comparisons
Michael Hudson
mwh at python.net
Mon Mar 29 09:21:01 EST 2004
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
More information about the Python-Dev
mailing list