Mark Dickinson wrote:
> On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <hrvoje.niksic at avl.com> wrote:
>> The other day I was surprised to learn this:
>>
>>>>> nan = float('nan')
>>>>> nan == nan
>> False
>>>>> [nan] == [nan]
>> True # also True in tuples, dicts, etc.
>
> That one surprises me a bit too: I knew we were using
> identity-then-equality checks for containment (nan in [nan]), but I
> hadn't realised identity-then-equality was also used for the
> item-by-item comparisons when comparing two lists. It's defensible,
> though: [nan] == [nan] should presumably produce the same result as
> {nan} == {nan}, and the latter is a test that's arguably based on
> containment (for sets s and t, s == t if each element of s is in t,
> and vice versa).
>
> I don't think any of this should change. It seems to me that we've
> currently got something approaching the best approximation to
> consistency and sanity achievable, given the fundamental
> incompatibility of (1) nan breaking reflexivity of equality and (2)
> containment being based on equality. That incompatibility is bound to
> create inconsistencies somewhere along the line.
>
> Declaring that 'nan == nan' should be True seems attractive in theory,
> but I agree that it doesn't really seem like a realistic option in
> terms of backwards compatibility and compatibility with other
> mainstream languages.
Totally out of my depth, but what if the a NaN object was allowed to
compare equal to itself, but different NaN objects still compared
unequal? If NaN was a singleton then the current behavior makes more
sense, but since we get a new NaN with each instance creation is there
really a good reason why the same NaN can't be equal to itself?
~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4