[PYTHON MATRIX-SIG] Let's get going

Graham Hughes graham@fishnet.net
Tue, 12 Sep 1995 21:21:25 -0700

At 12:17 PM 9/12/95 +0300, you wrote:
>I prefer the mathematical, not elementwise multiplication. We are handling
>matrixes here (not tables!). Besides, one doesn't want to define the * 
>operator for complex numbers to do 'elementwise' multiplication, does she? 
>It would be meaningless!

Ah, but would it be?

Part of the reason why I wanted to do elementwise multiplication and
division is that matrix multiplication is nearly trivial with inner and
outer products. E.g.; you want your `normal' complex multiplication? Try

outer_product(lambda x,y: x+y,lambda x,y: x*y, v1, v2)

which can easily be all a member function calls. Similarly, (BTW, this works
with APL's data parallelism; depending on how we implement outer_product it
may be a bit nastier), matrix multiplication is this:

outer_product(lambda x,y: x+y, lambda x,y: x*y, m1, m2.transpose())

(Note the transposition.)

Finally, we reach the question of efficiency. No matter how you implement
it, matrix multiplication will be slow(er). Divison, besides which it won't
always work, will take roughly forever; APL is quick on this note, but
that's because to do matrix multiplication you use a special purpose
function. This, and the odd dimension requirements for matrix
multiplication, are why I'm not fond of having the `mathematical' methods be
the default. Besides, if we do it that way, we can treat one-dimensional
vectors consisting of only one element (i.e. [3] or some such) essentially
as scalars, which is a parallelism I like; whereas matrix multiplication and
division will take 10 times as long to get the same answer.

>In my opinion, the overloading of operators is to make things more clear 
>than to mess them up. The elementwise multiplication by * operator would 
>be clear to anyone with no knowledge of matrices, but not to someone who 
>knows what matrices are.

Correct me if I'm wrong, but doesn't matrix multiplication use a special
syntax all its own? All the matricies are either boxed or in boldface, some
times they even use 'X' instead of a dot, all to make absolutely sure that
the reader gets the point. Great efforts are taken to make sure that anyone
reading knows that the multiplication does weird stuff here (because weird
stuff happens; where else do you take two things of unequal size and come up
with something else with a possibly completely different size?)

I understand the engineering tendency to think in terms of matrix
multiplication, but there is a precedent for divorcing it from the matrix
addition; the two are radically different operations.

>Perhaps a table object should be developed for elementwise calculation?

Probably not; too much common code to make it worthwhile. Besides, since
Python is typeless, we *cannot* distinguish between multiplication by a
scalar or by a matrix. There is no typeof() function to distinguish them. To
avoid bizarrities concerning *scalar* multiplication, we must use
elementwise multiplication. If this were C++, we could use two seperate
operator *()s, but it's not. And we're pleased about that most of the time :)

>That is not a good reason. It's more confusing to use mathematical
>definition for some, and non-mathematical definitions for other operators,
>as in your '+ vs. *' example. 

To you. To the person coming from APL, J or some other similar languages,
it's the other way around. Plus it raises problems dealing with scalar

Graham Hughes <graham@fishnet.net>  Home page http://www.fishnet.net/~graham/
``I think it would be a good idea.'' -- Mahatma Ghandi, when asked what he
                                        thought of Western civilization
finger for PGP public key.

MATRIX-SIG  - SIG on Matrix Math for Python

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