[Numpy-discussion] An historical precedent for matrix operation symbols
Paul F Dubois
paul at pfdubois.com
Fri Mar 8 08:25:06 CST 2002
To sum up my previous postings: I prefer the "constructor" notation, not
the funny-attribute notation. However, I believe an efficient matrix
class can be done in Python on top of a numeric array object. Shadow
classing just doesn't seem to be an overhead problem in most cases. The
coding for MA is very complicated because of its semantics are so
different; for Matrix it would be much less complicated.
When I designed Basis (1984) I was faced with the operator issue. The
vast majority of the operations were going to be elementwise but some
users would also want matrix multiply and the solution of linear
systems. (Aside: a/b meaning the solution x of bx = a, is best
calculated not as (b**-1) * a but by solving the system without forming
the inverse.)
My choice was: matrix multiply and divide were *!, /!.
This was successful in two senses: the users found it easy to remember,
and you could implement it in the tokenizer or just in the grammar. I
chose to make it a token so as to forbid internal spaces, but for Python
it could be done without touching the tokenizer, and it doesn't use up
any new symbols.
Symbols are precious; when I designed Basis I had a keyboard map and I
would cross out the keys I had "used up". If I were Guido I would be
very reluctant to give up anything valuable like @ for our purposes.
One should not have any illusions: putting such operators on the array
class is just expediency, a way to give the arrays a bit of a dual life.
But a real matrix facility would have an abstract base class, be
restricted to <= 2 dimensions, have realizations including symmetric,
Hermitian, sparse, tridiagonal, yada yada yada.
Another aside: There are mathematical operations whose output type
depends not just on the input type but some of these other
considerations. This led me to believe that the Numpy approach is
essentially correct, that the type of the elements be variable rather
than having separate classes for each type.
More information about the Numpy-discussion
mailing list