RetroSearch Browse

Thu Mar 25 07:54:39 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-March/098866.html

Am 24.03.2010 22:47, schrieb Mark Dickinson:
> On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> ..
>>> Neither is necessary, because Python doesn't actually use == as the
>>> equivalence relation for containment testing:  the actual equivalence
>>> relation is:  x equivalent to y iff id(x) == id(y) or x == y.  This
>>> restores the missing reflexivity (besides being a useful
>>> optimization).
>>
>> No, it does not:
>>
>>>>> float('nan') in [float('nan')]
>> False
> 
> Sure, but just think of it as having two different nans there.  (You
> could imagine thinking of the id of the nan as part of the payload.)

That's interesting.  Thinking of each value created by float('nan') as
a different nan makes sense to my naive mind, and it also explains
nicely the behavior present right now.  Each nan comes from a different
operation and therefore is a "different" non-number.

Of course, float being an immutable type, there is some reason to expect
that all values created by float('nan') should be identical, but after all,
datetime is an immutable type as well, but you wouldn't expect

   datetime.now() in [datetime.now()]

to be true.  The only wart left is that you can't distinguish different
nans by their string representation -- this could be remedied by making
it ``"nan-%s" % id(self)``, but that looks a bit ugly to me.

Georg

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

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

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