[PYTHON MATRIX-SIG] Vector-style operations vs. matrix operations

James Hugunin jjh@mama-bear.lcs.mit.edu
Wed, 13 Sep 95 12:04:44 -0400


Short personal intro, feel free to skip:

Hi, my name's Jim Hugunin and I'm a PhD student working in MIT's Laboratory  
for Computer Science.  My current work involves designing speech  
recognition systems.  My Master's thesis involved the fabrication and  
computer modeling of superconducting transistors (using the Bogoliubov  
deGennes equations if anyone cares) so I'm reasonably familiar with  
numerical modelling in both the EE and the physics communities.

I'm the one who wrote the initial proposal for the matrix object that Jim  
Fulton posted to start this discussion, so you already know my opinions on  
most of these issues.  I've also implemented a matrix object (on top of Jim  
Fulton's) which provides most of the capabilities described in the proposal.

Real comments begin here:

First, some posts seem to be placing too much stock in the name "matrix"  
object.  I propose that the name should be changed to either table or tensor  
(as mentioned by Chris Chase) if this is necessary to quell the arguments  
that a "matrix" should behave like a mathematical "matrix".  (Note: I have  
no objections to arguments in favor of matrix-multiplication for "*", I just  
don't think they should be based on something as arbitrary as the object's  
name).

Next, I'd like to add my vote to those in favor of element-wise operations.  
 This just seems to me to be the most general purpose sort of functionality  
that could be provided by an object that stores contiguous blocks of  
homogeneous data.  I think that all of the same element-wise operations  
should be provided as are provided for the int and float objects (note this  
is a small change to my proposal).  This makes a table object simply a way  
of storing a multi-dimensional block of homogeneous data-elements, that can  
be operated on in exactly the same way as the equivalent scalars in python  
with greatly improved performance.

I also completely agree with Konrad Hinsen's suggestion that J's rank  
system be used for table objects.  This is in fact a very minor change to my  
original proposal.  J's rank system is simply a clearer way of expressing  
my dimensionality coercion ideas.

Chric Chase suggests:
    Generalized inner and outer products (taking user specified binary
    operators) would also be very helpful.

I'm curious to better understand this proposal.  If it means defining an  
outer product that can take python binary functions as it's arguments, I  
would argue that it would be incredibly inefficient (compared to native C),  
and therefore might as well be implemented in python as a set of "helper"  
functions.

If it means specifying only primitive binary arithmetic operations (like  
"+" and "*") then I think that it could be implemented efficiently, but I  
would really like to see some examples of where this would be useful (other  
than matrix multiplication which will probably be done with special purpose  
code for efficiency reasons anyway).

All of the above comments also relate to proposals for specialized "map"  
and "reduce" functions for tables/matrices.  Unless there is some large  
efficiency gain possible, I'd rather see these implemented in python than C.

-Jim Hugunin    hugunin@mit.edu

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

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