[Numpy-discussion] Status of numeric3 / scipylite / scipy_core
oliphant at ee.byu.edu
Thu Mar 17 17:17:33 EST 2005
Tim Hochberg wrote:
> Perry Greenfield wrote:
> Yes! Not index arrays by themselves, but the indexing system as a
> whole is already on the verge of being overly complex in numarray.
> Adding anything more to it is foolish.
I think the solution given in the PEP is not especially complex. In
fact, I think it clarifies what numarray does so that it does not appear
"mind-blowing" and can actually be implemented in a reasonable way.
> 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):
This is an interesting idea!!! I'm not one to criticize naming (I
can't seem come up with good names myself...)
> 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.
I think adapter objects will be useful in the long run. We've already
got X.flat right? It's too bad you couldn't have thought of this
earlier (we could have added this to Numeric years ago and alleviated
one of the most disparaged things about Numeric). But, I'm afraid that
some form of index arrays are already with us, so we really won't be
able to get rid of them entirely. I'm just trying to make them
reasonable. The addition to the Numarray behavior I've added is not
difficult (in fact I think it clarifies the numarray behavior --- at
least for me).
More information about the NumPy-Discussion