Operators for matrix: current choices (Was Matlab vs Python ...)

[William Tanksley]

On Tue, 18 Jul 2000 14:21:12 -0700 (PDT), Huaiyu Zhu wrote:

>Before we plunge into this thing which may turn out to be more laborious
>than MatPy itself, we need to get a handle on what's involved.  Let me make
>a list in order of my preference.  Please jump in at any point that's both
>feasible and interesting enough for someone to actually do it:

Just some comments.

>1. Make a pure python way to introduce additional operators, like
>   import NewOperator
>   NewOperator.define(".+", "__dotadd__")
>   NewOperator.define("+=", "__add_ab__")
>   NewOperator.define(":=", "__copy__")

This isn't feasable -- it would require modifying the lexer and parser at
runtime, which would be a MAJOR change and can have unpredictable results.
(You know what I mean if and only if you've ever written a compiler with a
grammar.)

>6. Maintain two classes: E and M.  

>   Advantage: no need for new operators.
>   Disadvantage: artificial casting likely to be maintenance nightmare,
>   because we change objects while we really want to change operators.

>   A variant: only use .E for elementwise.  Always return matrixwise.  This
>   is simply just using casting to help select among two methods denoted by
>   the same binary symbol.  Does not look much better than 4 but worth
>   considering. 

This, IMO, is actually the best of the solutions.  It imitates paper
notation for a lot of transformations, and it's fully as fast as using
special functions for dot (and other) multiplication.  It doesn't involve
any unneeded duplication.

>8. Use preprocessor on another file extension like .mpy

I hope not.  Ugh.

>9. Use a miniparser for expressions in strings.
>   Advantage: artificially looks like pure python.

It's not artificial -- you'd be using Python's own parser.  However, I
agree with your list of disadvantages; I don't like it.

>10. Use list comprehension.

>	Advantage: apparently none.
>	Disadvantage: admitting that elementwise operations cannot be
>	encapsulated.  Need a new syntactic structure with brackets, loops,
>	dummy variables, scope delimitor (: or ;) implicitly parrallel for loops
>	and implicit casting.  Yuck!!!

>Note: I dislike some of the proposals because they look like ugly hacks to
>use the abundance of class names, method names, function names and string
>literals to walk around what is clearly just a shortage of a few operator
>symbols.  But I don't think we can reach consensus on such issue anyhow.
>
>If there is no more proposal forthcoming, I will adopt a combination of
>options 3 and 4, and hoping for someone to come up with 1.  The largest
>problem with this approach is this: If we can't guarantee the patch is
>usable everywhere, do we want everybody using these operators?  Will it run
>on another machine, or even another version of python?  If such a status
>persists for a long time I guess all codes will settle into a local optimum,
>something like
>
>(a.emul(b))*(c.emul(d))
>
>and an opportunity would be lost, even if in reality most people actually
>like (a.*b)*(c.*d).  This incidentally also removes an opportunity to see if
>elementwise operators might be useful elsewhere, like
>
>["%5.2f", "%-8s", "%.2g"] .% [pi, 'short', 1]
>
>["Alice", "Bob", "Charlie"] .+ "is" .+ ["girl", "boy", "boy"]
>
>The argument "if it finds wide-spread use we may put it in the language" has
>a severe limitation - if it is technically very difficult for users to use a
>feature that's not in the language, it will unlikely to find wide-spread use
>and may never get into the language.  That's why I really hope something
>like 1 can come up.
>
>Inputs greatly appreciated.
>
>
>Huaiyu
>
>
>
>
>
>
>
>
>
>
>
>


-- 
-William "Billy" Tanksley