[PYTHON MATRIX-SIG] Time for recap?
Fri, 29 Sep 95 15:18:02 -0400
> I like the general idea of going with APL/J style multidimensional
> I liked Konrad's sample implementation even though I agree an actual
> implementation would have to have a contiguous representation.
> I'm not sure about Konrad's particular notation for changing the rank
> of an operator (though it is very cool that that is possible in
> Python!). More thought needs to go in details like this.
I found Konrad's implementation enlightening regarding the ways of APL. I
have a different notation for many of the things he does. Some of this
notation should be discussed ASAP, but I'll save that for a later message.
> I think the best way to proceed is to use the built-in operators for
> APL/J style elementwise operations and to have the specific 2D linear
> algebra operations as methods.
I agree completely!
> 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.
> I have one idea I would like to float by this group. How about
> separating out the representation and the structure?
> I believe I've seen C/Fortran matrix packages that made quite good use
> of this. The representation would be a simple 1-dimensional sequence.
> You'd normally not see or use this, but it would be there if you
> needed access to it (e.g. for passing to C/Fortran code).
> There's a simple way to map an index in an N-dim array into an index
> in the 1-dim representation array (Fortran compilers use it all the
> time :-).
> To make efficient use of this, I propose that slicing and indexing, as
> long as they return an object of rank >= 1, return an object that
> points into the same representation sequence.
> I propose one additional feature (which I believe I saw in Algol-68;
> some matrix packages may also use it): add a "stride" to each
> dimension (including the last). This makes it possible to have slices
> reference discontiguous parts of the underlying representation, and
> even to represent a transposed version!
I agree almost completely with this specification. In fact, in many ways
this is exactly what I have been implementing on top of Jim Fulton's
original matrix object. (btw - the real or the imaginary part of a complex
matrix are also particularly easy to represent using this style).
The one thing that I've been doing differently is that slices (ie. a[1:5])
are returned by value rather than by reference. This was Jim Fulton's
original implementation and I kept it because it was similar to the notion
of slicing a list. Conceptually, I have no problems with treating slices
the same as any other discontinuous index (ie. a[(range(1,5), range(4,6))])
and returning them by reference. Actually, I like the simplicity of being
able to think of every index into a matrix returning by reference.
I would be interested in hearing other opinions on this issue.
> If we do things just right, it may be possible to pass in the sequence
> to be used as the representation -- it could be a Python list, tuple
> or array (from the array module).
This is an interesting notion, but I can't see what it would gain over
using a 1d C-array of basic types as the representation. It wouldn't be too
hard to expand the definition of basic type to include (PyObject *)'s if
you'd like to have the possibility of a matrix of "real" python objects.
I should have time to finalize some of these things this weekend so that I
can make an alpha version of a matrix object written in C available to
interested members of this group on Monday. It is surprisingly similar to
Konrad's sample implementation in python (though a lot bigger, uglier and
yet faster owing to it's C-implementation).
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com