Re: [Tutor] Implementation of list comparison operators
> On Jan 17, 2019, at 16:13, Peter Otten <__pete...@web.de> wrote: > > David Rock wrote: > >> both a and nan are floats, so why does a == a work, but nan == nan >> doesn’t? > > It does "work", it's only produces a result you didn't expect ;) > Python just follows the standard here > > https://en.wikipedia.org/wiki/IEEE_754 > https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN > > Also: > > https://stackoverflow.com/questions/10034149/why-is-nan-not-equal-to-nan Touché :-) — David Rock da...@graniteweb.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
David Rock wrote:
>
>> On Jan 17, 2019, at 13:40, Peter Otten <__pete...@web.de> wrote:
>>
>> David Rock wrote:
>>
>>>
>>> Isn’t this a bit artificial, though? The reason this is False is
>>> because
>>> you explicitly tell it to return False when using equality. That’s not
>>> the same thing as using __eq__ without overriding it’s behavior
>>> internally.
>>
>> Sorry, I don't understand that argument. My point wasn't whether it's a
>> good idea to write objects that compare unequal to themselves -- such
>> objects already exist:
>>
> nan = float("nan")
> nan == nan
>> False
>>
>> I only warned that a list containing such an object does not meet the
>> intuitive expectation that list_a == list_b implies that all items in
>> list_a compare equal to the respective items in list_b.
>
> It’s certainly a valid warning. My confusion came from you using an
> arbitrary example of creating a class that breaks the logic in an override
> rather than one that already exists as a concrete example. To me, your
> class example looked contrived.
>
> What is it about the float(“nan”) example that makes this break?
>
> In [5]: nan = float("nan”)
>
> In [6]: type(nan)
> Out[6]: float
>
> In [7]: nan == nan
> Out[7]: False
>
> In [8]: a = 1.1
>
> In [9]: a ==a
> Out[9]: True
>
> In [10]: type(a)
> Out[10]: float
>
> both a and nan are floats, so why does a == a work, but nan == nan
> doesn’t?
It does "work", it's only produces a result you didn't expect ;)
Python just follows the standard here
https://en.wikipedia.org/wiki/IEEE_754
https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN
Also:
https://stackoverflow.com/questions/10034149/why-is-nan-not-equal-to-nan
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
On Thu, Jan 17, 2019 at 03:05:17PM -0600, David Rock wrote: > In [7]: nan == nan > Out[7]: False > > In [8]: a = 1.1 > > In [9]: a ==a > Out[9]: True > both a and nan are floats, so why does a == a work, but nan == nan > doesn’t? They both "work", because they both do what they are designed to do. Equality between two floats works something like this: if either number is a NAN: return False if both numbers are 0.0 or -0.0: return True if both numbers have the same bit-pattern: return True otherwise return False -- Steve ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
> On Jan 17, 2019, at 13:40, Peter Otten <__pete...@web.de> wrote:
>
> David Rock wrote:
>
>>
>> Isn’t this a bit artificial, though? The reason this is False is because
>> you explicitly tell it to return False when using equality. That’s not
>> the same thing as using __eq__ without overriding it’s behavior
>> internally.
>
> Sorry, I don't understand that argument. My point wasn't whether it's a good
> idea to write objects that compare unequal to themselves -- such objects
> already exist:
>
nan = float("nan")
nan == nan
> False
>
> I only warned that a list containing such an object does not meet the
> intuitive expectation that list_a == list_b implies that all items in list_a
> compare equal to the respective items in list_b.
It’s certainly a valid warning. My confusion came from you using an arbitrary
example of creating a class that breaks the logic in an override rather than
one that already exists as a concrete example. To me, your class example
looked contrived.
What is it about the float(“nan”) example that makes this break?
In [5]: nan = float("nan”)
In [6]: type(nan)
Out[6]: float
In [7]: nan == nan
Out[7]: False
In [8]: a = 1.1
In [9]: a ==a
Out[9]: True
In [10]: type(a)
Out[10]: float
both a and nan are floats, so why does a == a work, but nan == nan doesn’t?
—
David Rock
da...@graniteweb.com
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
David Rock wrote:
>
>> On Jan 17, 2019, at 12:39, Peter Otten <__pete...@web.de> wrote:
>>
>> One obscure detail of the implementation of list equality:
>>
>> In Python an object can be unequal to itself:
>>
> class A:
>> ... def __eq__(self, other): return False
>> ...
> a = A()
> a == a
>> False
>
> Isn’t this a bit artificial, though? The reason this is False is because
> you explicitly tell it to return False when using equality. That’s not
> the same thing as using __eq__ without overriding it’s behavior
> internally.
Sorry, I don't understand that argument. My point wasn't whether it's a good
idea to write objects that compare unequal to themselves -- such objects
already exist:
>>> nan = float("nan")
>>> nan == nan
False
I only warned that a list containing such an object does not meet the
intuitive expectation that list_a == list_b implies that all items in list_a
compare equal to the respective items in list_b.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
> On Jan 17, 2019, at 12:39, Peter Otten <__pete...@web.de> wrote: > > One obscure detail of the implementation of list equality: > > In Python an object can be unequal to itself: > class A: > ... def __eq__(self, other): return False > ... a = A() a == a > False Isn’t this a bit artificial, though? The reason this is False is because you explicitly tell it to return False when using equality. That’s not the same thing as using __eq__ without overriding it’s behavior internally. — David Rock da...@graniteweb.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Implementation of list comparison operators
One obscure detail of the implementation of list equality: In Python an object can be unequal to itself: >>> class A: ... def __eq__(self, other): return False ... >>> a = A() >>> a == a False However, the list assumes that (a is a) implies a == a, so >>> [a] == [a] True ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
