[Numpy-discussion] Status of numeric3 / scipylite / scipy_core

[Tim Hochberg]

Paul Barrett wrote:

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

I'm saying that irregular indexing should be spelled differently that 
regular indexing. Consider this little (contrived) example:

X[(2,3,5,7,11)] = Y[[2,4,8,16,32]]

Quick! What's that mean using numarray's indexing rules? (which I 
believe are close enough to the proposed rules to not make a difference 
for this case.) Oddly, it means:

X[2,3,5,7,11] = take(Y, [2,4,8,16,32])

That's not entirely numarray's fault. For historical reasons X[a,b,c,d] 
is treated by Python exactly the same X[(a,b,c,d)]. And the above case 
is not going to get programmed on purpose, except by the pathological, 
but it could crop up as a bug fairly easily since in most other 
circumstances tuples and lists are equivalent. Even the more standard:

X[2,3,5,7,11] = Y[[2,4,8,16,32]]

Is not exactly easy to decipher. Contrast this to the proposed:

X[2,3,5,7,11] = Y.atindex[2,4,8,16,32]

Where it's immediately apparent that one indexing operation is irregular 
and one is regular. Note that you still need to use indexing notation on 
atindex, and thus it needs to be some sort of helper object vaguely 
similar to the new flat. This is because you also want:

Y.atindex[2,4,8,16,32] = X[2,3,5,7,11]

to work and it wouldn't work with function call syntax. This doesn't 
entirely insulate one from the weirdness of using tuples as indexes 
described above, but it should be a big improvement in this regard. 
Irrespective of that, it's much clearer what's going on with the 
spelling of the two types of indexing differentiated. It also opens the 
door for other types of irregular indexing, since it may turn out that 
there is more than one type of irregular indexing that may be useful as 
mentioned by Perry (?) earlier.

-tim