[Numpy-discussion] basearray / arraykit

[Tim Hochberg]

Sasha wrote:

> On 5/10/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
>> ...
>> I'm thinking that fancy-indexing should be re-factored a bit so that
>> view-based indexing is tried first and then on error, fancy-indexing is
>> tried.   Right now, it goes through the fancy-indexing check and that
>> seems to slow things down more than it needs to for simple indexing
>> operations.
>
>
> Is it too late to reconsider the decision to further overload [] to
> support fancy indexing?   It would be nice to restrict [] to view
> based indexing and require a function call for copy-based.  If that is
> not an option, I would like to propose to have no __getitem__ in the
> basearray and instead have rich collection of various functions such
> as "take" which can be used by the derived classes to create their own
> __getitem__ .

This is exactly the approach taken by arraykit.

>
> Independent of the fate of the [] operator, I would like to have means
> to specify exactly what I want without having to rely on the smartness
> of the fancy-indexing check.  For example, in the current version, I
> can either do x[[1,2,3]] or x.take([1,2,3]).  For a 2d x I can do
> x.take([1,2,3], axis=1) as an alternative to x[:,[1,2,3]], but I
> cannot find an equivalent of x[[3,2,1],[1,2,3]].
>
> I think [] syntax preferable in the interactive setting, where it
> allows to get the result with a few keystrokes.  In addition [] has
> special syntactic properties in python (special meaning of : and ...
> within []) that allows some nifty looking syntax not available for
> member functions.  

This is why I was considering using pseudo attributes, similar to flat, 
for my basearray subclass. I could hang [] off of them and use all of 
the normal array indexing syntax. I haven't come up with ideal names 
yet, but it could look something like:

x[:3, 5:]   # normal view indexing
x.at[[3,2,1], [1,2,3]] # integer array indexing
x.iff[[1,0,1], [2,1,0]] # boolean array indexing.

> On the other hand in programming, and especially in
> writing reusable code specialized member functions such as "take" are
> more appropriate for several resons. (1) Robustness, x.take(i) will do
> the same thing if i is a tuple, list, or array of any integer type,
> while with x[i] it is anybodys guess and the results may change with
> the changes in numpy. (2) Performance: fancy-indexing check is
> expensive. (3) Code readability: in the interactive session when you
> type x[i], i is either supplied literally or is defined on the same
> screen, but if i comes as an argument to the function, it may be hard
> to figure out whether i expected to be an integer or a list of
> integers is also ok.

Sounds reasonable to me.

-tim