[Numpy-discussion] take semantics (bug?)
Robert Kern
robert.kern at gmail.com
Tue Dec 5 22:19:03 EST 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()
>>>>>> a[inds]
>>> array([1, 2, 3])
>>>>>> a.take(inds)
>>> 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[0].
>>
>> .take() doesn't; it simply tries to convert its argument into an array. It
>> can
>> 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
x[i, j]
.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:
http://projects.scipy.org/scipy/numpy
--
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
More information about the NumPy-Discussion
mailing list