Home Original page

Discussion: Introducing new operators for matrix computation

Matt Feinstein mfein at aplcomm.jhuapl.edu
Thu Jul 13 08:33:49 EDT 2000 
On Wed, 12 Jul 2000 19:32:32 GMT, hzhu at knowledgetrack.com (Huaiyu Zhu)
wrote:

>
>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.
>

My own preference would be 'as consistent as possible with MATLAB,
with some caveats'-- this would mean option 1, with some thought about
changes in places where the current MATLAB syntax drops the ball
(IMO). I don't think MATLAB's inelegances should be preserved for the
sake of consistency. On the other hand, I think it's very important to
make the translation from MATLAB language to Python as automatic as
possible.

The main thing I'd think about in addition to standard MATLAB syntax
is a natural 'prolongation' syntax. In other words, contexts in which
the vector [1 2 3] is naturally expanded to [1 2 3;1 2 3;1 2 3;...].
This operation is part of one of the basic strategies in
vectorization-- prolongation, followed by some vectorized operation,
followed in turn by selection or contraction. Presently, MATLAB can do
this, but only in an idomatic and peculiar way. There are some dangers
in this route-- it encourages a tendency to syntactical trickiness--
the history of the APL language provides a case in point and a
warning.

One thing that MATLAB does correctly (again, IMO) is its relatively
relaxed attitude towards distinctions among scalars, 1x1 vectors &
matrices as well as among different kinds of nulls and NAN's. You can
test for these distinctions if you want to, but generally MATLAB will
just quietly do the right thing. There's a tendency to get wrapped up
in fine distinctions in cases where there's really no ambiguity about
what the programmer wants to do.

--
Matt Feinstein
mfein at aplcomm.jhuapl.edu
Organizational Department of Repeated
and Unnecessary Redundancy
More information about the Python-list mailing list