[PYTHON MATRIX-SIG] A problem with slicing

[James Hugunin]

I'm eager to see what Guido has to add in his "(More later.)", because at  
the moment I'm slightly confused by the trend in this discussion.  If the  
point is that the proposed slicing semantics are a bad idea because they'd  
require basic changes to the language, then I'd answer that no changes are  
in fact necessary.  If instead he is offering to open up this portion of the  
language to change in the hopes of creating a more "consistent design",  
then I think there are some interesting possibilities.

In my opinion, the slicing semantics for matrices as currently proposed  
seem reasonable and can be implemented with zero changes to the core python  
language by using getitem and setitem for mapping objects (I know this  
because I've implemented them within the matrix module that way).

However, there is a good argument to be made saying that

- a[:3, :4]

is a lot more consistent with the current implementation of lists than

- a[(range(3), range(4))]

In addition, something like

- a[3:, 4:]

is a lot clearer than

- a[(range(3,shape(a[0]), range(4, shape(a)[1]))]

However, one thing that I really like about the proposed indexing scheme is  
that I can say

a[((1,3,5), (2,4,6))]

and get back the desired non-contiguous chunk of the array.  This is  
occasionally very useful from an efficiency point of view, and  
unfortunately, efficiency is something that needs to be kept in mind for  
large numeric arrays.

If I had my wish, I would change the syntax of python so that  
start:step:stop, or start:stop was a shorthand for creating a range object  
(with some reasonable way of specifying start or stop as defaults).  This  
would not need to change the semantics of basic sequence indexing, as these  
could be handled as a special case.  I think that ":" should obviously be of  
higher precedence than ",".  There are no cases that I can think of where  
it would be a reasonable thing to have a tuple as one element in a range.

With this change, and the I feel completely reasonable proposal that "," be  
allowed for tuple creation within an index, then multidimensional arrays  
could be made to behave in a manner completely consistent with lists.  And  
this would require minimal changes to the run-time architecture of slicing  
and indexing.



On a slightly different track:

I've been playing with another technique for indexing a matrix, borrowed  
from matlab.  I've implemented indexing matrices with a matrix of booleans  
(integers) that is the same size as the matrix being indexed (this only  
makes sense for a setvalue).  This is trivially done using the mapping  
semantics, and combined with some matrix comparision operators I've found  
this quite useful.

ie. a.gt(x) is a matrix less than operator.  (I'd prefer to use "a < x",  
but the point of this is to explore what can be done without changing the  
core python language that all of us love so much).

a = matrix([1,2,3,4,5,4,3,2,1])
a[a.gt(3)] = 3
print a
--> [1,2,3,3,3,3,3,2,1]


I don't think that this is a substitute for any of the indexing methods  
currently being discussed, but I want to make sure that all candidate  
indexing methods are brought up as early on in the discussion as possible in  
order to ultimately create a coherent (rather than haphazard) indexing  
system.

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================