[PYTHON MATRIX-SIG] Time for recap?
Sat, 30 Sep 95 14:53:50 -0400
> > > Likewise, instead of my earlier wild ideas about multidimensional
> > > slices, I propose to use a slice() method that can produce arbitrary
> > > slices; e.g. a[k][i:j] would be equivalent to a.slice(k, (i,j)).
> > I disagree slightly here. I still prefer a[(k, range(i,j))] for Guido's
> > example. This makes a[(k, [x,y,z])] possible.
> Ah. I was writing from memory, and forgot this feature. I don't like
> it. How many times do you have to select a more or less arbitrary
> group of rows/columns from a matrix? It makes the slice representation
> bulkier -- contiguous slices can be stored (in C) as 4 ints per
> dimension, while random selections will require a variable-length
> list of indices per dimension. (It is also wasteful to have to
> generate the full range of numbers when what you mean is a contiguous
As far as implementation efficiency is concerned, I have implemented things
so that each dimension requires 2 ints and an int pointer. If the
dimension corresponds to a quasi-contiguous slice then the pointer is set to
NULL, and the ints give the number of indices and a stride. If the
dimension corresponds to a random slice, then the pointer points to an array
of indices. So, very little efficiency is lost for quasi-contiguous
slices, and yet it is still possible to represent random slices.
My current favorite use for arbitrary indexing is for image zooming. ie:
img = [1,2,3,4]
a = img[((1,1,2,2,2,3,3,3,4,4),)]
a = [1,1,2,2,2,3,3,3,4,4]
This is a reasonably efficient approach for coarse-zooming in to even large
2d images, and it will work for on any arbitrary matrix (unlike C-code
which I must write a special case for each matrix).
My other reason for really liking this feature is that matlab supports it,
and I would really like to see this object support as large a subset of
matlab code as possible.
> To write a tuple of length one, you can't write (1) --
> you have to write (1,). (A tuple of length 0 is () -- easy.) For
> consistency, I think I'll have to make a[(1,)] mean the same as a,
> if a[(1,2)] is the same as a[1,2]. Finally, notice that to the object
> being indexed, there is no way to tell a[(1,2)] from x=(1,2); a[x].
I disagree completely with this. The proposal to allow tuplizing inside of
's I feel should be completely compatible with "tupleizing" outside of
brackets. Just as you can right in python "a = 1," and a will be a 1d
tuple, you should be able to write a[1,] and have the index be a 1d tuple.
Of course, this will ultimately be your decision.
> If we extend this rule to N-dimensional indexing, a[sequence], for
> some sequence of integers whose elements are i, j, k, ..., should be
> equivalent to a[i][j][k]..., and we can't make a[(1,2,3)] mean
> a while at the same time interpreting a[[1,2,3]] as a[1:4].
> (Sooner or later, you'll be passing a vector to the index. Then the
> question will arise, should this have the same meaning as a tuple or
> as a list. It's better if they all three mean the same.)
I actually agree with you completely on this. I have used Jim Fulton's
generic sequence indexing functions in order to be sure that the index can
happily be either a tuple or a list or a matrix (which actually should be
special cased and optimized at some point).
Either I missed a point somewhere, or you have a different interpretation
of my indexing scheme than I do. As some examples:
a[1,2,3] == a[(1,2,3)] == a[[1,2,3]] == a
^ if this becomes allowed
a[(1,2,3),] == a[((1,2,3),)] == [a, a, a]
However, if there is sufficient disapproval of this method of indexing,
a.select() is a reasonable alternative.
Just my two cents worth.
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org