[PYTHON MATRIX-SIG] Time for recap?

Hinsen Konrad hinsenk@ere.umontreal.ca
Fri, 29 Sep 1995 09:45:05 -0400


   I liked Konrad's sample implementation even though I agree an actual
   implementation would have to have a contiguous representation.

The two main reasons for choosing the nested list implementation
(remember, that was before I even knew about the Matrix SIG) were:
1) the possibility of using nested lists as a notation for
   array constants; this means I rarely have to type Array().
2) many of the array operations can be written concisely as
   recursive functions.
The second reason is less important for our purposes, but we do
have to think about a convenient notation for array constants.
We might actually use nested lists and provide a coercion function
that transforms them into 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.

Definitely. I am not too pleased with it myself, mostly because the
specification of ranks for functions with more than one argument
is cumbersome, requiring two sets of square brackets. But I couldn't
find another way to specify rank in Python!

   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.

Why such a division? There is no clear borderline between "elementwise"
and "linear algebra". If we should distinguish at all between methods
and functions, I'd propose to use methods for procedures that change
an array in place and functions for those that return a new array.


   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).

I have also seen C++ packages that make the representation available
in this way, and it makes sense.

   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.

Again, there are C++ classes that do this, and of course this makes
slicing very efficient. On the other hand, it makes element assignment
more complicated, since the array may have to be copied first.

   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!

Again, this is used in C++ classes... There's a book that I have
recommended before (Scientific end Engineering C++, by John J. Barton
and Lee R. Nackman) that describes a matrix class with all the
implementation features you just proposed.

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. A                | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------

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

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