Discussion: new operators for numerical computation

[Huaiyu Zhu]

Now that Guido has given the go-ahead for adding new operators for numerical
computation, let us consider carefully how to allocate this new resource,
taken into account Tim's guidelines.

Here's a list of issues that come to mind:

1. What symbols to use.

   It seems that we can more or less concentrate on using either . or @
   together with existing math operators.  Issues:

   (1) Use . or @

   (2) Which is matrixwise or elementwise

   (3) Compatibility: NumPy uses * for elementwise, MatPy uses * for
       matrixwise.

   (4) Similarity with Matlab (but not really compatibility). 

   Notation: To avoid confusion, I'll adopt matlab notation and invent a set
   of unique names in the following discussions:

        matrix          element      names (with prefix m or e)
          +               .+            add
          -               .-            sub
          *               .*            mul
          /               ./            div
          \               .\            sol
          ^               .^            pow

    Therefore the statement "Use /@ for msol" or "Use /@ for matlab\" or
    "Use a/@b for solve(a,b)" are equivalent.

    In your followup you may add a line like

    Notation: * is matrixwise and .* is elementwise
    Notation: @* is matrixwise and * is elementwise

    so people would understand your examples.


2. Precedence, scope and other properties:

   This is largely settled (and that's what Greg's patch does)

   - They have exactly the same properties as their ordinary counterparts.

   - The e and m versions give identical results on numbers.  


3. Their behavior on other objects:

   Even though they are supposed to be used for numerical objects only, what
   if user writes [10,20].+[1,2]?

   - Exception: no __dotadd__ or __rdotadd__ defined

   - Behave as eadd and give [11,22]

   - Behave as current + and give [10,20,1,2]

   The last one is dead, people writing [].+[] either made a typo of
   [].member+[] or want eadd.

   The second seems most sensible and least surprising, but it does need to
   include list in the implementation of eadd.

   My understanding is that Tim wants the first one.  So let's leave it
   there lest it drags other bits down.


4. The magic words:

   This really depends on issue 3 above.  

   - If it is intended that these thing should never acquire a meaning
     outside numerical computation, they should be called __mmul__,
     __emul__, etc, because that would describe the intension well.

   - If other classes, like UserList, are allowed to use them, it's better
     to use __dotmul__, __atmul__, etc, so the association with the symbols
     are strong.

   - Someone mentioned __altmul__ for @*, meaning alternative mul.


5. Other bits and pieces:

   - How to deal with left division?

    (1) Use sol(a,b)
    (2) use /@ or /.
    (3) use %

   - How to deal with power?  It is already two characters

    (1) Use ** and .** or @**
    (2) Steal ^ with .^ or @^ (not much chance, just mentioning here)

   - Do we want a copy operator := which is different from =?  It allows
     efficient code.  The following code does not change A
         B := A
         B += C
     This definitely will be usable for other classes. Call it __copy__?

   - Since augmented assignment almost certainly will get in the core, we
     need to consider combining them.  A few possible opinions

     (1) Just use prefix . or @ to mean e or m, use suffix = to mean in
         place assignment, and all are well defined.

     (2) a .**= 3 looks too long.  Don't combine them.

     (3) allow .+=, etc but ban .**=.


These are the things that come to mind.  Now, opinions, please.

Huaiyu

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