Discussion: new operators for numerical computation

[Huaiyu Zhu]

On 20 Jul 2000 13:48:05 GMT, Aahz Maruch <aahz at netcom.com> wrote:
>In article <Pine.LNX.4.10.10007191505070.1129-100000 at rocket.knowledgetrack.com>,
>Huaiyu Zhu  <huaiyu_zhu at yahoo.com> wrote:
>>
>>        matrix          element      names (with prefix m or e)
>>          +               .+            add
>>          -               .-            sub
>
>I am strongly opposed to operators of the form ".+".  What happens if
>take an expression of the form "5.+matrix"?  No, that goes against the
>Python rule of having zero ambiguity.

I'd like to rehash this argument.  Assuming * for matrix and .* for element.

The operators + - * / are defined completely according to linear algebra, so
they will check dimension mismatch and raise exceptions.  This is a very
imortant guarantee.  Without this there can be a lot of very hard to track
bugs.

The operators .+ .- .* ./ are defined elementwise with broadcasting (ie
automatically extending missing dimensions).  This is the default behavior
of current Numeric package and is accepted by its current users.  One
example usage: to plot a graph

z = sin(x.**2 .+ y.**2)

is more efficient than the matlab way

[x, y] = meshdomain(x,y)
z = sin(x.^2 + y.^2)

because extension is not needed until the addition.

So both sets of operators are well defined using consistent rules.  All the
operators are different.  All of them are useful algorithmically, not just
for lazy figers.  

Then why allow .* ./ but ban .+ .-?  There may be a perception that .+ .-
are somehow too similar to + -. Specifically, a+b==a.+b if size(a)==size(b).
But then there is also a*b=a.*b when a is number, etc. Accepting .* ./ while
avoiding .+ .- makes the rules more complicated for no apparent gains.

Besides, if we are to have only one version of a+b, what should be its
semantics?  It is unthinkable to change current Numeric bahavior.  It is
also difficult to explain why a*b has dimension checking but a+b does not.

If the . itself is the problem then we must treat that problem, by using @,
for example, instead of making up a rule to exclude part of the problem.

Another solution.  The same problem exists for .* as well.  Using [] to
denote matrix.  Then is 1.*[1]==[1.] or 1.*[1]==[1] true?  To be consistent
with current implementation, it seems the answer has to be [1.].  One way to
solve the problem is to make

number .+ matrix 

illigal, which can be done by leaving  __rdotadd__ undefined.

Huaiyu