[Numpy-discussion] take semantics (bug?)

Robert Kern 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()
>>>>>> 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:


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