[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
=================