Discussion: new operators for numerical computation

[Huaiyu Zhu]

On 20 Jul 2000 20:25:50 -0400, Warren B. Focke <moron at Glue.umd.edu> wrote:
>
>But I think also that we should consider not just user base, but code
>base - how much code is already out there that will break under the
>various suggestions.

Ah, I see where the problem is!  No.  Not a single line of code. (well, see
below.) 

For ordinary numbers, all the operators are exactly the same.

For classes, they define their own __mul__ that is hooked to *.  This will
not change, unless you choose to redefine __mul__.

For the new operators, be it .* or @  or @*, they are not defined for
anything other than numbers.  Each class is free to define them in any
fashion.  

If your module uses, either

from Numeric import array
a, b, c = array ...
matrixmultiply(a,b)*c

or 

from MatPy import Matrix
a, b, c = Matrix ...
a*b.e_mul(c)

nothing would cease to work, whatever the meaning of the new operators.
(This is not strictly true, because MatPy actually uses __dotmul__ but
s/__dotmul__/e_mul/ would do the trick.)

Only when you decide to actually use the new operators which were not
available today, then you need consider their meaning.  In fact, even if
NumPy and MatPy uses opposite meaning for * and @*, not a single line of
existing code would break.  These two packages already work perfectly with
each other, and I do use both in production code.

I see the eventual unification of MatPy and NumPy somewhat along the line of
migration from the regex to re module.  That is, it would be possible in the
future to define a new package with a different name, with an interface that
has advantage of both, or better than both.  People could just use the new
package for new code, which could coexist with old modules as well.  They
can migrate their code at leisure time.

After writing this, I have the feeling that maybe after all it is not so
important to consider what's the semantics of these operators.  We do agree
on the syntax of these operators.  Is this enough for the PEP?  I don't
know. If it is called __dotmul__ this might already be enough?  

We are already allowed to define two interfaces.  I don't see why
introducing new operators would make one of them disallowed (break).  That's
why I'd be more interested in new code than existing code, as the purpose of
these operators is to make writing future codes easier.

Just my 2c.

Huaiyu