[Python-Dev] [Fwd: Discussion: Introducing new operators for matrix computation]

Paul Prescod paul@prescod.net
Wed, 12 Jul 2000 17:52:56 -0500

You can guess my instinctive reaction...still, I feel for these guys
competing with pricy domain-specific software.

-------- Original Message --------
Subject: Discussion: Introducing new operators for matrix computation
Date: Wed, 12 Jul 2000 19:32:32 GMT
From: hzhu@knowledgetrack.com (Huaiyu Zhu)
Reply-To: hzhu@users.sourceforge.net
Organization: Giganews.Com - Premium News Outsourcing
To: python-list@python.org
Newsgroups: comp.lang.python

We are at a crucial juncture concerning introduction of new operators
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
   that next candidate on the standard keyboard is @.

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

   a@b  is equivalent to a*b,  overloaded using __mmul__   and
   a@/b                  a/b                    __mrdiv__  and
   a/@b                  b/a                    __mldiv__  and
   a@@b                  a**b                   __mpow__   and

   He indicates similar constructions can be added easily.  

We intend to add these operators together with Thomas Wouters's
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.
- Consistent with Matlab.
- Consistent with current MatPy.
- Convenient for matrix computations.
- 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.
- Consistent with NumPy
- Can use a@/b and a/@b as matlab a/b and a\b.
- Can use a@b as inner product so that a@b works irrespective of whether
  and b are row or col operators.
- Inconsistent with current MatPy.  Need great effort to switch.
- Using two symbol operator for matrix mul is cumbersome for long
- It kind of looks ugly.

3. Use a@b as matrix mul, and a*b as elementwise mul.  This has most of
pros and cons of choice 2, except 
- Single symbol operators for matrix mul and element mul.
- Can't use a@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
   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
   MatPy and NumPy at the same time.  a*b will be matrixwise for MatPy
   elementwise for NumPy.  This is convenient when each usage is
dominant in
   some part of a program.  Removing this difference and MatPy will lose
   lot of appeal when it is needed.

3. Although it is relatively difficult to switch the usage in MatPy, it
   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
scientists: Use ^ and @^ for matrix power.  Currently ^ is defined as
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
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
fundamental reason they cannot use Python for doing the same thing,
that we are allowed to add this little additional operator.  :-) What
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
more important than complex numbers, but this is off topic.

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

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