Discussion: new operators for numerical computation

Gregory Lielens gregory.lielens at fft.be
Thu Jul 20 05:45:10 EDT 2000


> Based on my ramblings I'll toss out a proposed operator set for the
> pack to feed upon:
> 
>         Operator        Name
>           .*             matmul
>           ./             matdiv
>           /.             matsol
>           .** or(?) .^   matpow
>           *              mul
>           /              div
>           %,^,&,|,**     mod, xor, and, or, pow
> 
> With broadcasting / nonbroadcasting decided by the individual packages.
> 
> My 3 cents.
> 
> -tim

I agree almost completely with Tim's arguments, except for the choice of
. instead of @.
I would prefer @ because 
 .* means elementwise for Matlab users, 
 matlab notation is more or less a standard for numerical matrix
computation (at least, it is the most widely used)
 inversing the meaning of * and .* in Python compared to the "standard"
is IMO asking for far more trouble than to introduce
 new symbols...

Here is thus my proposal (which is in fact currently implemented,
together with the aug-assign patch...I should post the complete patch so
that everybody can check it...but where?)

          Operator        Name
           @              matmul
           @/             matdiv
           /@             matsol
           @@             matpow
           *              mul
           /              div
           %,^,&,|,**     mod, xor, and, or, pow

@ was choosen over @* because @ is already quite heavy by itself...

@@ follow naturally, and @/, /@ the only way I came to differentiate
matsol of matdiv...
These three symbol are probably too heavy, but it is maybe not a bad
thing, imho, as they are potentially very CPU-intensive, the heaviness
can act as a kind of warning: use with care. Moreover, I think these
three operator work well with matrices, not 
with general Nd array. @ on the other hand, should be defined as an
inner product
a=b at c is a(i1,...,in,j1,...,jm) = Sum_over_k (
b(i1,...,in,k)*c(k,j1,..,jn))
the three ugly @@, @/,/@ are thus a lttle less general that the "pretty"
(not so ugly is a better way to describe it :)) @.

I do not have introduced @+, @- for the same reason as Tim: there is no
fundamental difference between matrix and element  addition and
substraction, they would be introduced as a way to specify wether
broadcast or error is asked for when matrix (or Nd arrays) are not of
the same shape. In fact, I just verfied, .+ does not exist in
matlab...Personnaly, I vote to a + , - , *, / broadcast always, @, @/,
/@ never (what should be the meaning of bradcasting for these?)

There is only one element division, /, compared to 2 matrix dvisions, @/
and /@. (not sol operator, only a matsol one)
This is imho not an issue, as

A matsol B <> B matdiv A, but should sol exist, A sol B == B div A
(for Matlab users, A\B <> B/A, but A.\B == B./A. . in fact, .\ is almost
never used in Matlab)

My concern with this notation is that

-it is not using @ as a systematic extender of previous notation. We
could use @* instead of @, and @** for @@, but
 it is less aesthetic imho...

- As Tim said, @ is heavy...The first character which I planned to use
was in fact ° (degree, a small circle located at the same height as "),
but it is not in ASCII table and not on US qwerty keyboard (on my azerty
keyboard, it is easier to type than @). Should unicode (or 8 bit Latin-1
character table) be supported, and ° be accessible worldwide, I choose
it anytime over @:

A°B is pretty!

- It eat the @ character, which was not previously used and could be
reserved for new uses...but we are speaking of a new use, aren't we?

Greg.



More information about the Python-list mailing list