Discussion: new math operators

[Huaiyu Zhu]

A summary is attached and the subject title is changed to make the thread
more intelligeable.

>Use of parentheses for matrix operators that Konrad Hinsen proposed
>appears to be the best solution I've seen so far. But perhaps the two
>camps won't be able to agree which should be the default, in which case
>there should be two different modules based on the same Numeric core with
>different operator mappings previously suggested. I don't necessarily see
>that a lack of agreement on this issue should prevent adding the new
>operators to Python as long as everyone agrees with the operator syntax.
>But adopting one scheme (ours of course :-) would certainly be best.

Agreed.  I've answered another post of the same concern, but this is worth
making clear: introducing new operators is meant to help everyone, and no
one's code should break.

One way to adopt unified scheme is to invent a new package that is better
than both of the current ones.  In the mean time, in order not to break
anyone's code, both current packages should remain supported, for a very
long time.  They can already coexist peacefully today, there's no reason
they would not in the future just because of some new operators are
available.

So, perhaps we need to summarize the first round and concentrate on the
remaining issues.  Here's my personal summary of the firs round (highly
opinionated)

========================================================================

We agree that there are two types of operators, matrixwise and elementwise.

We agree that they should have completely identical syntactic properties.
They behave identically on numbers.

We agree that the new operators, whether elementwise or matrixwise, should
not have default meaning on objects other than numbers.

Essentially three representations are suggested

.op
@op
(op)

where op is a combination of special characters.  Surprisingly (maybe not,
considering the math-oriented constituency), the third option draws the most
praise and almost not criticism.  It has more variations and have more
potential for the future.  Despite that, imo, it is unlikely to be accepted
eventually, because it would not play well with by non-math audience. I'll
leave it out and let its proponents to summarize and build a strong case.

Down to .op and @op, where op is an existing binary operator. There is
argument for both.  Using . may be confusing to current syntax (floats).
Using @ takes one of the only three "free" symbols on the ascii keyboard,
and @ looks too dense (like a letter).

Which is matrix and elementwise?  It is unlikely to reach any agreement on
this one.  One initial fear was that choosing one would break codes for the
other.  It was clarified that whichever is chosen, current interfaces should
be supported for compatibility.

Most discussants are against introducing both @op and .op so that both camp
will have it.  So the option comes down to the following only choice: matpy
and numpy using exactly the oposite meaning for these operators.

Here's my analysis why this might work.  Numpy users who's never touched
matpy would notice nothing changed, except matrixmultiply can be replaced by
an operator.  Matpy users who's never touched numpy would notice nothing
changed, except __dotmul__ can be replaced by an operators.  Old code remain
working even without change.  Those who use both are already accustomed to
the fact that * means two different things depending on object type.  Now
that there are convenient operators there's even less reason to have both
types in the same module, thereby less confusion than before.

What about new users?  Which do they choose, and will they get confused?
They should be advised to initially choose only one.  The difference is not
mainly on * or .*.  The discussion has made abundantly clear that there is
no intrinsic reason which should be which.  The difference between the two
packages is the emphasis placed on the different views of convenience - are
you more likely to slice through high dimensional arrays, or are you more
likely to do matrix algebra?  Do you want the distinction of arrays of
shapes (n,) (n,1) (1,n) (n,m), etc?  In fact, both packages are likely to
add conveniences existing in the other, so that eventually someone would
come up with a better design for grand unification.

The bottom line is: It is not necessary to break anyone's code in order to
claim "Yes, we have reached a verdict".

If this is adopted, no semantics will go into the specs for the operators.
It will be only for the distinction of elementwise and matrixwise operations
in multidimensional mathematical operations.  The actual meaning will be
assigned by the packages that implement them.  

There is a concern that any definition must include error bounds and other
technical specifications.  My view is that this belongs to the packages
making use of these operators, but not the operators themselves.  More
opinions on this?

There is a concern that the alternative + and - are not really needed, but
it is not clear which version of sematics should be dropped.  My view is
that these two have the same reason to be included as * and / (see a recent
post).  More opinions?

There is a discussion of meaning of multiarray multiplications.  It is
generally accepted that these involve explicit specification of indices. So
it is up to the classes of tensors-with-indices to overload these operators.

There is brief mention of other types of multiplications, like kronicker,
outer, lie, cross, etc.  They are shown to be variations of matrixwise
multiplications and are not as fundamental to worth special symbols.  They
can be implemented by functions names like kron(a,b).

Concerning left division (solve), it is somewhat accepted that we should not
grab % or | for this (nor use ^ for power) because that would be incosistent
with other domains, though that might be good choice if python had left them
free.

This is as far as I can remember.  Any major omissions?

If this is more or less the picture, we are down to selecting whether to use
@op or .op or (op), and whether solve need a symbol, and what it should be.

Huaiyu