[PYTHON MATRIX-SIG] Mutli-dimensional indexing and other comments

[Guido van Rossum]

> I also like Konrad's array function prototype that allows rank
> specification, e.g. product.over[1](b).  Guido did not like the rank
> specification via an index argument.  Could the rank be overriden
> using a keyword argument instead of an index argument,
> e.g. product.over(b,rank=1)?  Since keywords are commonly used to
> override default arguments this would seem a natural possibility.

Sounds good to me, though I'm still struggling with the concent of the
rank of an operator...

> Heirarchical (list-like) indexing:
> 
> Jim Fulton's proposal thinks of multi-dimensional arrays as being
> heirarchical so that a[i] returns a N-1 dimensioned array.  This
> allows him to use list style indexing, e.g. a[i][j].  This approach
> would seem to rule out flatten indexing (one-dimensional indexing) and
> multi-dimensional slicing, e.g. would a[2:9][1:5] just end up being
> equivalent to a[3:7]?

Yes.

> Perhaps that is what is wanted.

Not necessarily, but it's the only thing that's possible given the
various constraints and the current language implementation.  While
a[i,j] could easily be added (meaning a[i][j]), a[i:j,k:l] would
require major re-engineering of a complicated piece of code.  I
proposed a.slice((i,j), (k,l)) to express this.

> I am confused about proposals for array slices to be references.  In
> Jim's proposal, assignment is by copy and access is by reference.
> Then am I correct in understanding that for b=a[i] (a is
> two-dimensional) changing elements of b will not change a?

No.  Assignment to a simple name (e.g. "b") will always be by
reference, this is fundamental in the language.  However, *slice*
assignment has to copy (e.g. b[i:-1j] = a[i-1:j]), and I have proposed
that slice references (a[i:j] used in an expression) of arrays return
a reference to the original elements of a.  E.g. after b = a[i:j],
assignment to elements of b will change the corresponding elements of
a.  This is different from slice assignments for Python lists, but
seems to be the most useful rslice semantics for arrays.

> In general, I have not been able to keep straight the various
> proposals.  It seems that most issues have been concerned with
> implementation issues or with limiting extensions so they will not
> break the current language.

Indeed, such are the practicalities of extending a language that has
been used and developed extensively by/for thousands of users over the
past five years.

> Instead of diving into the implementation questions I would like to
> present my views on multi-dimensional indexing for arrays.  Then I
> would like to know how the current proposals fit into this view.

An approach that I like, at least in theory.

[What followed was too long for me to digest completely.]

> Why should we limit the hamstring the capabilities of an array
> extension just to avoid internal Python changes?

Because nobody wants to do the work.

> Additionally, while they might be useable in scripts, they will be
> inefficient for extensive interactive use.

Surely you mean "too much to type" and not "inefficient to execute".
Even though Python is quite usable interactively I don't think its its
real strengths lie there, and I don't think that interactive use
should be used as an argument in favor or against certain solutions.

--Guido van Rossum <guido@CNRI.Reston.VA.US>
URL: <http://www.python.org/~guido/>

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

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