[Numpy-discussion] basearray / arraykit

Sasha ndarray at mac.com
Wed May 10 13:43:04 EDT 2006


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__ .

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.  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.




More information about the NumPy-Discussion mailing list