[Python-Dev] PyObject_RichCompareBool identity shortcut

[Robert Kern]

On 4/27/11 11:54 PM, Guido van Rossum wrote:
> On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>> On 2011-04-27 23:01 , Guido van Rossum wrote:
>>> And I wouldn't want to change that. It sounds like NumPy wouldn't be
>>> much affected if we were to change this (which I'm not saying we
>>> would).
>>
>> Well, I didn't say that. If Python changed its behavior for (float('nan') ==
>> float('nan')), we'd have to seriously consider some changes.
>
> Ah, but I'm not proposing anything of the sort! float('nan') returns a
> new object each time and two NaNs that are not the same *object* will
> still follow the IEEE std. It's just when comparing a NaN-valued
> *object* to *itself* (i.e. the *same* object) that I would consider
> following the lead of Python's collections.

Ah, I see!

>> We do like to
>> keep *some* amount of correspondence with Python semantics. In particular,
>> we like our scalar types that match Python types to work as close to the
>> Python type as possible. We have the np.float64 type, which represents a C
>> double scalar and corresponds to a Python float. It is used when a single
>> item is indexed out of a float64 array. We even subclass from the Python
>> float type to help working with libraries that may not know about numpy:
>>
>> [~]
>> |5>  import numpy as np
>>
>> [~]
>> |6>  nan = np.array([1.0, 2.0, float('nan')])[2]
>>
>> [~]
>> |7>  nan == nan
>> False
>
> Yeah, this is where things might change, because it is the same
> *object* left and right.
>
>> [~]
>> |8>  type(nan)
>> numpy.float64
>>
>> [~]
>> |9>  type(nan).mro()
>> [numpy.float64,
>>   numpy.floating,
>>   numpy.inexact,
>>   numpy.number,
>>   numpy.generic,
>>   float,
>>   object]
>>
>>
>> If the Python float type changes behavior, we'd have to consider whether to
>> keep that for np.float64 or change it to match the usual C semantics used
>> elsewhere. So there *would* be a dilemma. Not necessarily the most
>> nerve-wracking one, but a dilemma nonetheless.
>
> Given what I just said, would it still be a dilemma? Maybe a smaller one?

Smaller, certainly. But now it's a trilemma. :-)

1. Have just np.float64 and np.complex128 scalars follow the Python float 
semantics since they subclass Python float and complex, respectively.
2. Have all np.float* and np.complex* scalars follow the Python float semantics.
3. Keep the current IEEE-754 semantics for all float scalar types.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco