Discussion: new operators for numerical computation

[Huaiyu Zhu]

On Mon, 24 Jul 2000 20:34:40 GMT, Tim Hochberg <tim.hochberg at ieee.org> wrote:

>> b = a.I - a | u / (c.I + v/a*u) * v / a
>> 
>> b = a.I .- a .| u ./ (c.I .+ v./a.*u) .* v ./ a
>> 
>> b = a.I @- a @| u @/ (c.I @+ v@/a@*u) @* v @/ a
>> 
>> b = a.I (-) a (|) u (/) (c.I (+) v(/)a(*)u) (*) v (/) a

>The first is definitely the best. This does give me some sympathy for
>the reversing the sense of the operators in different packages
>proposal. Not enough, I don't think, but some. I think the second one
>is actually the worst: are you going to notice the difference between:
>
>b = a.I .- a .| u ./ (c.I .+ v./a.*u) .* v ./ a
>
>and 
>
>b = a.I .- a .| u ./ (c.I .+ v./a*u) .* v ./ a
>
>It seems that accidentaly using matrix when elementwise was meant and
>vise versa would be a huge problem.

Good point.  So .op is out.  (In matlab this is smaller problem because
elementwise operation is not so frequent.)

>The third is hard to parse because @ is so heavy, and the last case
>has parentheses problems. Blech. I went ahead and tried the other
>passible bracketing symbols:
>
>b = a.I [-] a [|] u [/] (c.I [+] v[/]a[*]u) [*] v [/] a
>
>b = a.I <-> a <|> u </> (c.I <+> v</>a<*>u) <*> v </> a
>
>b = a.I {-} a {|} u {/} (c.I {+} v{/}a{*}u) {*} v {/} a
>
>The [*] form looks a little better. The <*> form bugs me because <->
>looks like and arrow, but otherwise looks better than I expected. The
>{*} form looks no better than [*] form, and is less evocative of a
>matrix operation.

How do these compare with
 
 b = a.I ~- a ~| u ~/ (c.I ~+ v~/a~*u) ~* v ~/ a

The ~ is non-intrusive - the parenthesis are clearly visible.  It is not as
easily missed as a dot.

>My opinion: ".op" should be killed; any more consideration of this
>front should go to "@op" or "~op". "(op)" should probably also die and
>be replaced by "[op]" or, maybe, "<op>" or "{op}".

Here's a summary of symbols discussed so far

              Advantages                      Disadvantages
.op   clean[1], extend[1], 1c       conflict (float, member), easy to miss
@op   NC, extend[2], 1c             visually heavy
~op   NC, clean[2], extend[2], 1c   ?
(op)  NC, clean[1], extend[1]       confuse with existing ( )
[op]  NC, clean[2], extend[1]       confuse with existing [ ]
{op}  NC, clean[2], extend[1]       confuse with existing { }
<op>  clean[2],                     conflict? confuse with existing < >?
---------
Notes:
NC          no conflic with existing strucuteres.
extend[1]   future extension to multisymbol operators, like @%$
extend[2]   future extension to mixed multisymbol operators, like @name
clean[1]    visually clean individually
clean[2]    visually clean in formulas 
1c          one additional character

I agree that we should kill .op and (op).  But we can get rid of several
others as well.  The [op] and {op} have the similar disadvantage as ().
Consider, for example,

Matrix([[1],[2]]) [/] Matrix([[3]])
[ [a[*]b, a[/]b], [a[+]b,a[-]b] ]
[ {1:a{*}b, 2:b{/}a}, {"a":a{+}b, "b":a{-}b} ]

The form ~op~ mentioned sometime earlier is not better than any of the
brackets except (op).

It seems that @op is no better than ~op in every aspect.

So let's drop these as well. And we are left with only 
~op
<op>

When comparing ~op with <op>, I prefer the former, as there is not much need
to delimit both sides if there's only going to be one or two characters. The
~op is light weight enough that I'd be willing to go along with ~op for
linear algebra if that also means solve has a symbol.  

BTW, the ~ can also serves as a meta character for future extension of infix
operators (See the opeartor for everything thread).  Consider
a ~add b < c
a <add> b < c
This leaves the future open without committing anything.

Is there any problem associately with  ~op?

>I'm also starting to wonder if maybe there is no good, pythonic syntax
>to be added here. Perhaps more consideration should go into using the
>existing operators and making tranformations between elementwise array
>objects and matrix objects convenient.

Well, to a certain extent, because the ascii keyboard is limited.  Unicode
may be relief in the future.  However, this example has probably more than
average complexity. So we shouldn't expect it to be easy, even on paper.

I've been thinking about using the casting approach, but it does not seem to
be easy.  The maintenance is non-trivial when new methods and functions are
added.  The actual formula is not that bad, in fact,

 b = a.I - a.M | u.M / (c.I + v.M/a.M*u.M) * v.M / a.M

Huaiyu