[PYTHON MATRIX-SIG] A problem with slicing
James Hugunin
jjh@mama-bear.lcs.mit.edu
Thu, 14 Sep 95 14:41:39 -0400
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
=================