[PYTHON MATRIX-SIG] Time for recap?

James Hugunin jjh@mama-bear.lcs.mit.edu
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
> slice.)

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[1],
> 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[1][2][3] 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[1][2][3]
^ if this becomes allowed

a[(1,2,3),] == a[((1,2,3),)] == [a[1], a[2], a[3]]

However, if there is sufficient disapproval of this method of indexing,  
a.select() is a reasonable alternative.

Just my two cents worth.

-Jim

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

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