[Numpy-discussion] take semantics (bug?)
robert.kern at gmail.com
Tue Dec 5 21:19:03 CST 2006
Michael McNeil Forbes wrote:
> Robert Kern <robert.kern at gmail.com> wrote:
>> Michael McNeil Forbes wrote:
>>> What are the semantics of the "take" function?
>>> I would have expected that the following have the same shape and size:
>>>>>> a = array([1,2,3])
>>>>>> inds = a.nonzero()
>>> array([1, 2, 3])
>>> array([[1, 2, 3]])
>>> Is there a bug somewhere here or is this intentional?
>> It's a result of a.nonzero() returning a tuple.
>> __getitem__ interprets tuples specially: a[1,2,3] == a[(1,2,3)], also a[0,]
>> == a.
>> .take() doesn't; it simply tries to convert its argument into an array. It
>> convert (array([0, 1, 2]),) into array([[0, 1, 2]]), so it does.
> Okay. I understand why this happens from the code.
> 1) Is there a design reason for this inconsistent treatment of "indices"?
Indexing needs to handle tuples of indices separately from other objects in
order to support
.take() does not support multidimensional indexing, so it shouldn't try to go
through the special cases that __getitem__ does. Instead, it follows the rules
that nearly every other method uses (i.e. "just turn it into an array").
> 2) If so, is there some place (perhaps on the Wiki or in some source
> code I cannot find) that design decisions like this are discussed? (I
> have several other inconsistencies I would like to address, but would
> like to find out if they are "intentional" before wasting people's time.)
If they're recorded outside of the code, _The Guide to NumPy_, or the mailing
list, they're here:
"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
More information about the Numpy-discussion