On 4/27/11 11:54 PM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern<robert.k...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
