[PEP draft 2] Adding new math operators

[Huaiyu Zhu]

On Wed, 09 Aug 2000 21:24:37 GMT, Tim Hochberg <tim.hochberg at ieee.org> wrote:
>I'm out of love with the ~+ notation, so I'd like to see more serious
>discussion of the .E notation. However, there hasn't been a formal or
>even an informal attempt at describing how it would work, particularly
>at the edges. I'm going to put a very informal description below in
>the hope that it'll help the discussion along.

I like this attempt.  Let's see if this can go through.  Some questions and
comments.

>2a) If either c or d is a scalar (python float/int/complex or rank 0 array),
>    it is converted to the type of the other operand without complaint.

How are you supposed to implement that?  This is 55% of the issue (IMO).
For example, are you allowing x.E if x happens to be 3?  

>In addition, the additional operator approach only help here if the
>sense of the operators is the same for both MatPy and NumPy. Which
>means that, in effect, ~X would be matrixeise for both packages. I
>admit to having lost track of this thread for a while, but last I
>heard the wish was for ~X to be elementwise within MatPy.

Not like that.  If the difference is in operators, then you can stick with
one flavor of objects throughout a module, and use ~op for occasional
operation of the other flavor.

On the other hand, if the difference is in operands, you can't be sure the
flavor of the objects in any big chunk of code if both operations exist,
unless you set up a convention to always cast back to a given flavor after
each operation. That's what I think was the reason someone came up with the
"non-persistent-type" or "shadow" classes approach.  This is 40% of the
issue (IMO).

Personal experience: during the initial development of MatPy I once tried to
mix two flavors of objects in one piece of code (because I hadn't wrote
wrappers for all the functions needed) and it was a nightmare.  My
impression is that separation at module level is going to work.  Separation
at function (method) level is the extreme.  Mixing these within a function
is just a call for disaster.

Huaiyu