[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