[PYTHON MATRIX-SIG] Ranks and pseudo indices

[James Hugunin]

Konrad writes:

>    2) No more ranks of operators, instead Yorick style pseudo indices are  
>    used.  As a side effect of this, outer product is now a convenience  
function
>    rather than a method on ofuncs.
>
> As another side effect, we have lost some important functionality.
>
>    For functions of unbounded rank (currently the only kind of function
>    supported by my omathmodule) Yorick pseudo indices support a superset of  
>    what was possible to express using ranks and outer products.  There is no  
>    fundamental reason not to have both pseudo indices and ranks, I just think  
>    that it's conceptually cleaner not to mix the two up.
>
> The pseudo indices are not a replacement for ranks, but just a convenient
> notation for some structural functions. I like this notation very much,
> but we still need ranks. And as you said, there is no reason not to have both.
>

I'll look at your specific comments, but I don't yet find them convincing.

> So every construction with (pseudo) indices can be emulated with three
> structural functions of suitable rank. On the other hand, there are
> constructions that cannot be expressed with pseudo indices, for
> example all cases where a function rank is not a constant but a
> variable. In fact these can be handled in Python -- as opposed to
> Yorick -- by remembering that a[x,y,z] is really just a shorthand for
> a[(x,y,z)] and that the index tuple can be constructed from an
> expression, but that seems more like an implementation accident than a
> feature to me.

Actually, I do think that this is a feature, but I'd be curious for a good  
example of a case of this.

> More importantly, pseudo indices don't help in the least when it comes
> to reductions and general inner products that require the specification
> of an axis. Yorick does this by putting the function into the index
> list -- a clever idea, but I'd prefer to keep a clear distinction
> between functions and arguments. The current matrix module allows
> a second parameter to reduce() that indicates the axis, which is
> exactly how APL handles the problem.

I don't think that you're actually complaining about my current solution to  
this problem are you?

> But both these methods are restrictive. They are sufficient only
> for reductions with functions of unbounded rank. I can give an
> example of an actual application where this is not enough: I had
> a sequence of n rotation matrices, stored in a rank-3 array D of
> shape (n, 3, 3). Then the net rotation of this sequence could
> be obtained by matrixMultiply.reduce(D). Since matrix
> multiplication is a rank-2 function, I couldn't express this
> with the current matrix module.

This is unfortunate, but unless I hear of many more of these problems, I  
don't expect this to go away any time soon.  It's REALLY hard to add in  
function of finite rank to the Optimized FUNCtion scheme I'm currently  
using.  I spent a week and a half trying to make this happen and wound up  
with an ugly useless mess.  Since I can imagine very few cases where this  
sort of behavior is important, I'm very tempted to leave ofuncs as they are  
right now, only operating on unbounded functions.

> The bottom line: pseudo indices are convenient shorthands for
> the most common structural functions, but they are no replacement
> for the general function rank scheme we had in version 0.11.

You haven't convinced me of this (except in the cases of functions with  
finite rank) and I have a large number of reasons to ignore them.

-Jim

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

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