[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

[Steven D'Aprano]

Mark Shannon wrote:
> Steven D'Aprano wrote:
>> Mark Shannon wrote:
>>> Related to the discussion on "Not a Number" can I point out a few 
>>> things that have not be explicitly addressed so far.
>>>
>>> The IEEE standard is about hardware and bit patterns, rather than 
>>> types and values so may not be entirely appropriate for high-level 
>>> language
>>> like Python.
>>
>> I would argue that the implementation of NANs is irrelevant. If NANs 
>> are useful in hardware floats -- and I think they are -- then they're 
>> just as equally useful as objects, or as strings in languages like 
>> REXX or Hypertalk where all data is stored as strings, or as quantum 
>> wave functions in some future quantum computer.
> 
> So,
> Indeed, so its OK if type(NaN) != type(0.0) ?

Sure. But that just adds complexity without actually resolving anything.



>> Fundamentally, the problem is that some containers bypass equality 
>> tests for identity tests. There may be good reasons for that shortcut, 
>> but it leads to problems with *any* object that does not define 
>> equality to be reflexive, not just NANs.
[...]
> Just because you can do that, doesn't mean you should.
> Equality should be reflexive, without that fundamental assumption many 
> non-numeric algorithms fall apart.

So what? If I have a need for non-reflexivity in my application, why 
should I care that some other algorithm, which I'm not using, will fail?

Python supports non-reflexivity. If I take advantage of that feature, I 
can't guarantee that *other objects* will be smart enough to understand 
this. This is no different from any other property of my objects.



>>> The default comparisons will then work as expected for collections.
>>> (No doubt, making NaN a new class will cause a whole new set of 
>>> problems)
>>>
>>> As pointed out by Meyer:
>>> NaN == NaN is False
>>> is no more logical than
>>> NaN != NaN is False
>>
>> I don't agree with this argument. I think Meyer is completely mistaken 
>> there. The question of NAN equality is that of a vacuous truth, quite 
>> similar to the Present King of France:
>>
>> http://en.wikipedia.org/wiki/Present_King_of_France
[...]
> The problem with this argument is the present King of France does not 
> exist, whereas NaN (as a Python object) does exist.

NANs (as Python objects) exist in the same way as the present King of 
France exists as words. It's an implementation detail: we can't talk 
about the non-existent present King of France without using words, and 
we can't do calculations on non-existent/indeterminate values in Python 
without objects.

Words can represent things that don't exist, and so can bit-patterns or 
objects or any other symbol. We must be careful to avoid mistaking the 
symbol (the NAN bit-pattern or object) for the thing (the result of 
whatever calculation generated that NAN). The idea of equality we care 
about is equality of what the symbol represents, not the symbol itself.

The meaning of "spam and eggs" should not differ according to the 
typeface we write the words in. Likewise the number 42 should not differ 
according to how the int object is laid out, or whether the bit-pattern 
is little-endian or big-endian. What matters is the "thing" itself, 42, 
not the symbol: it will still be 42 even if we decided to write it in 
Roman numerals or base 13.

Likewise, what matters is the non-thingness of NANs, not the fact that 
the symbol for them has an existence as an object or a bit-pattern.



-- 
Steven