On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern
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.
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? -- --Guido van Rossum (python.org/~guido)