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

[Paul Prescod]

Huaiyu Zhu wrote:
> 
> ...
> Please jump in at any point that's both
> feasible and interesting enough for someone to actually do it:
> 
> 1. Make a pure python way to introduce additional operators, like
>    import NewOperator
>    NewOperator.define(".+", "__dotadd__")
>    NewOperator.define("+=", "__add_ab__")
>    NewOperator.define(":=", "__copy__")
> 
>    Advantage: Pure python.  Doesn't interfere with existing sytax.  May be
>    used for other operators.  Not in the core, only affect the module that
>    imports it.
>    Disadvantage: Said to be quite difficult to implement (Why?).

Parsers just do not work that way. Most parsers cannot be extended at
runtime. The language is defined at compile time by the grammar. The
only way to do it without rewriting Python's parser from scratch would
be to pre-declare every possible operator anyone might ever want in the
grammar.

> 2. Incorporate additional operators in python.  Either . or @.  Five to
>    eight would be enough for linear algebra.
> 
>    Advantage: Pure python.  Doesn't interfere with existing syntax.
>    Disadvantage: Fixed choice for everybody.  Unlikely to happen for quite
>    some time until everyone agrees on everything.

Agreed on all counts.

> 3. Maintain a patch for additional operators.
> 
>    Advantage: once built, everything is pure python.  Already have patch.
>    Disadvantage: Can't guarantee most users can patch python, so in practice
>    may need to maintain windows executable for download.

In the big picture, is that such a big deal?

> 4. Temporarily use a.mmul(b) and a.emul(b) before things settle down.  Then
>    define __dotmul__ = emul, or the like, when they are available.
> 
>    Advantage: immediately implementable.  Won't break anyone's code.  Can
>    also switch to  __atmul__ = mmul or other choices later.
>    Disadvantage: code somewhat cluttered.

Let me ask again, is that such a big deal?

> 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.

I don't think anyone proposed the pre-variant variant. It was always
supposed to always return matrixwise.

> ...
> 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.

Using method or function syntax is not "technically very difficult."
There are hundreds or thousands of NumPy users who can testify to that.
It is inconvenient. Yes. Inconvenience is the price of compromise.
Compromise is the price of sharing a language with people who are
uninterested your domain.

> ["%5.2f", "%-8s", "%.2g"] .% [pi, 'short', 1]

Eeek. That's really, really ugly. This is much more explicit:

i = ["%5.2f", "%-8s", "%.2g"] 
j = [pi, 'short', 1]
[for i,j in zip(list1, list2): i % j]

-- 
 Paul Prescod - Not encumbered by corporate consensus
Just how compassionate can a Republican get before he has to leave the 
GOP and join Vegans for Global Justice? ... One moment, George W. Bush
is holding a get-to-know-you meeting with a bunch of gay Republicans.
The next he is holding forth on education or the environment ... It is
enough to make a red-blooded conservative choke on his spotted-owl
drumstick.     - April 29th, Economist