[Numpy-discussion] Status of numeric3 / scipylite / scipy_core
barrett at stsci.edu
Fri Mar 18 07:23:08 EST 2005
Tim Hochberg wrote:
> My take is that having even one type of index array overloaded onto
> the current indexing scheme is questionable. In fact, even numarray's
> current scheme is too complicated for my taste. I particularly don't
> like the distinction that has to be made between lists and arrays on
> one side and tuples on the other. I understand why it's there, but I
> don't like it.
> Is it really necessary to pile these indexing schemes directly onto
> the main array object. It seems that it would be clearer, and more
> flexible, to use a separate, attached adapter object. For instance
> (please excuse the names as I don't have good ideas for those):
> X.rows[ind0, ind1, ..., ind2, :]
> would act like take(take(take(X, ind0, 0), ind1, 1), ind2, -1)). That
> is it would select the rows given by ind0 along the 0th axis, the rows
> given by ind1 along the 1st axis (aka the columns) and the rows given
> by ind2 along the -2nd axis.
> X.atindex[indices] would give numarray's current indexarray behaviour.
> Etc, etc for any other indexing scheme that's deemed useful.
> As I think about it more I'm more convinced that basic indexing should
> not support index arrays at all. Any indexarray behaviour should be
> impleented using helper/adapter objects. Keep basic indexing simple.
> This also gives an opportunity to have multiple different types of
> index arrays behaviour.
So you're saying that 1-D indexing arrays (or vectors) should not be
allowed? As Perry said earlier, 'slice(1,9,2)' is equivalent to
'range(1, 9, 2)'. I just consider slices to be a shorthand for
_regular_ indexing, whereas indexed arrays also allow for _irregular_
indexing. Or am I missing something?
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218
More information about the NumPy-Discussion