[PYTHON MATRIX-SIG] [munro@icf.llnl.gov: Re: Python Matrix extension tutorial]

[James Hugunin]

First off, I want to mention that I've looked at Yorick and find it a very  
impressive language for matrix manipulation.  If I was still trying to  
choose between languages like octave or matlab I'd find Yorick a clear  
winner.  The point of this python extension is to put these sorts of  
features within the python language so that so that we can simultaneously  
have access to the full power of that programming language (I know of no  
other "matrix" language in which you can write a full-scale web browser).

> In the handout at the meeting on page 7 is an example of the heavily
> used Yorick feature I mentioned: You have two arrays
>
>    b  with shape (2,3)
>    c  with shape (2,2,3)
>
> and you want to produce:
>
>    d[i][j][k]= b[i][k] + c[i][j][k]
>
> {The example would be much clearer if the ranks were given as (2,3)
> and (2,4,3), so it only made sense one way.}  In Python, this common
> operation is carried out by the expression:
>
>    d= add[1,2](b,c)
>
> Yorick has a special syntax for this same operation:
>
>    d= b(,-,) + c
>
> which I find much clearer

I think that Dave has a different concept of the operation being indicated  
by add[1,2](b,c) than I do, and than is really suggested by the notion of  
ranks.  add[1,2] means add the vectors in b to the matrices in c.  The  
notion of producing d[i][j][k]= b[i][k] + c[i][j][k] is conceptually  
different.  Nevertheless, I am intrigued by the idea of adding this to the  
language.

> I have the impression that the syntax would present very little
> difficulty in Python; on the model of the All and Reverse index
> objects, it would be easy to introduce a Pseudo object which did the
> reshape:
>
>    d= b[(All,Pseudo,All)] + c
>
> However, I imagine that the implementor will be loathe to change his
> notion of array conformability at this late date.  Nevertheless, you
> might as well ask to see what he says; probably the change wouldn't
> actually break any existing correct code, but merely give meaning to
> what would previously have produced a runtime error.  That "1-length
> wildcard" rule has been a tremendous winner for Yorick; if you can
> convince the Python guys to use it, I doubt they would ever regret it.

I think that this makes sense, and I'll have a go at implementing it for my  
next release.  The current version of the matrix object is 0.11 for a  
reason.  I'm perfectly happy to consider any and all suggested changes to  
the language.  I think I need to play with this one a little bit to see if I  
like it (for most of the things that I do ranks really are the right  
conceptual model), and I'll throw it out so that other people can begin  
playing with it and form their own opinions.

> Yorick has one other indexing syntax which has proven useful, which I
> call "rubber indices".  They address the problem of writing
> interpreted code which extracts slices of arrays when you don't know
> beforehand how many dimensions the array has.  An example is an
> opacity array for which you know that the most slowly varying index
> represents photon wavelength, but there might be zero, one, two, or
> three faster varying dimensions representing position in space.  These
> situations can probably be handled with Python's reshape operator, so
> again this is a question of ease of use.

I think that I like this idea.  Let me know if this is what you mean.

Currently I have (for c being a 3d array):
c[[0,]] <--> c[[0,All, All]]

Are you suggesting something like:

c[[Rubber, 0]] <--> c[[All, All, 0]]?

If you're in fact suggesting something else, I'd like to hear more.

-Jim

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

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