[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
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@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@b as inner product so that a@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@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@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@users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 
-- 
http://www.python.org/mailman/listinfo/python-list