[PEP draft 2] Adding new math operators

[Huaiyu Zhu]

On 10 Aug 2000 11:25:06 +0200, Konrad Hinsen <hinsen at cnrs-orleans.fr> wrote:

>In my experience, a more typical situation would be the following:
>
>- a, b, c, d are arrays
>- x and y are matrices
>
>Then you would write
>
>    matrix(a*b) * matrix(c*d) + x*y
>
>or using attributes
>
>    (a*b).matrix * (c*d).matrix + x*y
>
>both of which are perfectly readable.

Your example corresponds to 

    (a~*b) * (c~*d) + x*y

    (a.E*b.E).M * (c.E*d.E).M + x.M*y.M

Your notations are indeed quite readable on their own.  A slight problem is
that at first glance I read matrix(a*b) as matrix multiplication of a and b,
but this could be got used to.

The real problem is that the variables happen to come in the flavor suitable
for the input of your formula, and the output of your formula happen to be
in a flavor suitable for the rest of your program.  This formula therefore
is a switching point: you are in array context before it, and matrix context
after it.

What if there are many succesive switching points in your program?  Two
approaches have been discussed:

- Don't do extra convertion, keep a mental track of which variable is of
  which flavor.

- Always convert to one fixed flavor in a sufficiently large logical block
  of the code.

You are advocating the first, so the problem is with the context switching.
In practice, programmers would likely throw in extra .E and .M all over the
place just to make sure.

If the second approach is used, the shadow class approach is far better

  (a.E*b) * (c.E*d) + x*y  

If it could be cleanly implemented there'd be no need for extra operators.


>I have never seen any situation in which matrix objects (i.e. objects
>which are the result of matrix operations) are subsequently used in
>elementwise operations, with a result that has to be used in a matrix
>operation immediately afterwards.

Well, the majority of these cases come from using the "broadcasting rules".
You compute x and y (two axes) from linear algebra.  You compute a function
of them using elementwise operation instead of meshdomain as in matlab. Then
you transform z by linear algebra operations again.  This kind of operations
are quite common in data visualization, for example.

In statistical computations it is common to switch context of doing
elementwise computation (ie assuming independence between the components)
and do full matrix operation (taking into account correlation, etc). 

This is also the case for neural networks, where the operation within each
neuron are independent of each other, but the connections between neurons
involve matrix multiplication.

There are bound to be many more situations like these - they happen to be
what I'm familiar with.

Huaiyu