Discussion: Introducing new operators for matrix computation

hzhu at knowledgetrack.com.bbs hzhu at knowledgetrack.com.bbs
Wed Jul 12 15:30:10 EDT 2000


We are at a crucial juncture concerning introduction of new operators into
Python for matrix computation,

1. Experiences with Matlab show that different operators for matrix and
   elementwise operators are very important

2. It is difficult to add .* and ./ as . is already a valid token.  It seems
   that next candidate on the standard keyboard is @.

3. Gregory Lielens has just implemented a patch that could parse additional
   operators containing @

   a at b  is equivalent to a*b,  overloaded using __mmul__   and __rmmul__
   a@/b                  a/b                    __mrdiv__  and __rmrdiv__
   a/@b                  b/a                    __mldiv__  and __rmldiv__
   a@@b                  a**b                   __mpow__   and __rmpow__

   He indicates similar constructions can be added easily.


We intend to add these operators together with Thomas Wouters's augmented
assignment operators (+=,*=, etc) to MatPy, but before that several
decisions need to be made.  First, the main choices:


1. Use a*b as matrix mul, and a@*b as elementwise mul.
Pros:
- Consistent with Matlab.
- Consistent with current MatPy.
- Convenient for matrix computations.
Cons:
- Inconsistent with NumPy
- How to differentiate left and right div (matlab a\b and a/b)?


2. Use a@*b as matrix mul, and a*b as elementwise mul.
Pros:
- Consistent with NumPy
- Can use a@/b and a/@b as matlab a/b and a\b.
- Can use a at b as inner product so that a at b works irrespective of whether a
  and b are row or col operators.
Cons:
- Inconsistent with current MatPy.  Need great effort to switch.
- Using two symbol operator for matrix mul is cumbersome for long formulas.
- It kind of looks ugly.


3. Use a at b as matrix mul, and a*b as elementwise mul.  This has most of the
pros and cons of choice 2, except
Pros:
- Single symbol operators for matrix mul and element mul.
Cons:
- Can't use a at b as inner product.


Just to add to the agony, here are a few contrary views:

1. Consistency with Matlab is not necessarily good.  In Matlab operators
   default to matrix (cf * and .*) but functions default to elementwise (cf
   exp and expm).  In Python ** is defined by __pow__.  Should it be
   consistent with pow the function or ** the operator?

2. Consistency with NumPy is not necessarily good.  Currently one can use
   MatPy and NumPy at the same time.  a*b will be matrixwise for MatPy and
   elementwise for NumPy.  This is convenient when each usage is dominant in
   some part of a program.  Removing this difference and MatPy will lose a
   lot of appeal when it is needed.

3. Although it is relatively difficult to switch the usage in MatPy, it is
   still a good time if we deem this to be A Good Thing.  When the status is
   changed to beta from alpha it would be next to impossible to switch.


To throw you completely off the track, here is one additional feature
request that would great please mathematicians and greatly annoy computer
scientists: Use ^ and @^ for matrix power.  Currently ^ is defined as xor
which is of sufficiently low level that is unlikely to occur with matrix
computations.  Note that this is not in our plan right now.


One other thing that will be of great efficiency value (whenver somebody
comes forward to do it) is to parse := as assignment.  This way we can let
a=b be simple reference assignment without creating a new Matrix object.


The implementors of both previous patches have cautioned that Guido is
unlikely to adopt the patch for the .* or @* operators.  But I'm quite
confident that he can be persuaded.  There is a large number of users of
Matlab and Octave (maybe even more than users of Python), and there is no
fundamental reason they cannot use Python for doing the same thing, provided
that we are allowed to add this little additional operator.  :-) What other
incentives are needed to persuade Guido?  Here's a quote from Gregory,

> they make a huge difference in readability of code dealing with linear
> algebra, in particular when using small matrices.  Such operators explain
> partly the popularity of Matlab-like tools, imho.

I can argue that linear algebra is very important for Python, perhaps even
more important than complex numbers, but this is off topic.

So all your comments, suggestions and flames a invited.  I just have a small
request: As this is getting too long, please reply separately to different
parts of this article, so that the discussion threads remain manageable.


--
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net



More information about the Python-list mailing list