[Numpy-discussion] Status of numeric3 / scipylite / scipy_core
tim.hochberg at cox.net
Thu Mar 17 12:20:22 EST 2005
Perry Greenfield wrote:
> Before I delve too deeply into what you are suggesting (or asking),
> has the idea to have a slice be equivalent to an index array been
> changed. For example, I recall seeing (I forget where), the suggestion
> X[:,ind] is the same as X[arange(X.shape), ind]
> The following seems to be at odds with this. The confusion of mixing
> slices with index arrays led me to just not deal with them in
> numarray. I thought index arrays were getting complicated enough.
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 suppose it may be useful, but I would be good to give some
> motivating, realistic examples of why they are useful. For example, I
> can think of lots of motivating examples for:
> using more than one index array (e.g., X[ind1, ind2])
> allowing index arrays to have arbitrary shape
> allowing partial indexing with index arrays
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
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
> Though I'm not sure I can think of good examples of arbitrary
> combinations of these capabilities (though the machinery allows it).
> So one question is there a good motivating example for
> X[:, ind]? By the interpretation I remember (maybe wrongly), I'm not
> sure I know where that would be commonly used (it would suggest that
> all the sizes of the sliced dimensions must have consistent lengths
> which doesn't seem typical. Any one have good examples?
> On Mar 17, 2005, at 1:32 AM, Travis Oliphant wrote:
>> Travis Oliphant wrote:
>>> - Where there is more than one index array, what should replace the
>>> single-axis subspaces that the indexes are referencing? Remember,
>>> all of the single-axis subspaces are being replaced with one
>>> "global" subspace. The current proposal states that this indexing
>>> subspace should be placed first and the "remaining subspaces" pasted
>>> in at the end.
>>> Is this acceptable, or can someone see a problem??
>> Answering my own question...
>> I think that it makes sense to do a direct subspace replacement
>> whenever the indexing arrays are right next to each other. In other
>> words, I would just extend the "one-index array" rule to
>> "all-consecutive-index-arrays" where of course one index array
>> satisfies the all-consecutive requirement.
>> Hence in the previous example:
>> X[:,ind1,ind2,:,:] would result in a (10,2,3,4,40,50) with the
>> (20,30)-subspace being replaced by the (2,3,4) indexing subspace.
>> result[:,i,j,k,:,:] = X[:,ind1[i,j,k],ind2[i,j,k],:,:]
>> Any other thoughts. (I think I will implement this initially by just
>> using swapaxes on the current implementation...)
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the NumPy-Discussion