Operators for matrix: current choices (Was Matlab vs Python ...)
William Tanksley
wtanksle at dolphin.openprojects.net
Wed Jul 19 13:34:42 EDT 2000
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
More information about the Python-list
mailing list