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

[Penfold]

I'm sure Im jumping into a discussion where its already been thrashed to
death but ...

Huaiyu Zhu <huaiyu_zhu at yahoo.com> wrote in message
news:Pine.LNX.4.10.10007180134360.9411-100000 at rock.localdomain...
> This is a summary of what's discussed so far.
>
> On Tue, 18 Jul 2000, Moshe Zadka wrote:
> > ... we really meant that we'll help yo.
>
> Thanks!  I see where compile() is called.  But how is the parser itself
> called in python?  Only used as C function?  Now that we have a patch to
add
> the new operators, is it possible to assemble these into a module?
>
> 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:
>
> 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?).

I'd expect it would be ...
(i) you're asking that the grammer be dynamically changed *as* the module
is being parsed.
(ii) are you going to restrict the possible new tokens
(iii) How does the python interpreter work ... for example the expression
a+b
results in byte code of the form
LOAD_FAST a
LOAD_FAST b
BINARY_ADD

That is, the BINARY_ADD operation deals with the issues of whether these are
instance types (and thus __add__, __radd__, __coerce__
etc should be invoked).  At least thats what Ive always believed (never
checked the source ;-)  ).  So what gets generated
for a .* operation?  An explicit call? does coercion, or the equivalent of
__radd__ ever happen? What happens when a and b
are not classes? [well, a TypeError obviously?]

I mean there are issues there ;-)

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

<mini rant>
What, really, is the point in this.  Its obvious why you want them, but why
does everyone else?
This is clearly a *domain specific* problem, which is yours, that you would
like Python to look like
MatLab.

+, / * are all good operators. When I read code and I see a+b, I dont know
what a and b are, but I can guess the
general effects/properties of the expression a+b.

If I read a @ b, what the hell does that mean?? It means *nothing* unless I
know MatLab.  Whats worse,
coders will use it for all sorts of things, all of them different.  Sure,
they can do that with + but generally dont, its got an
"implicit" meaning.

But why stop here, why not proliferate the language with #!'s. Hell, I want
python to be more like perl,
why cant I use all sorts of meaningless operators to do so?  Why, this is
python, if I wanted to do
that I should be using perl [or MatLab ;-)]

Analogy:
    Problem: Why do I have to write x.sendMessage(y.createMessage(txt))?  I
should be able to write x &^% (y *&^ txt)
    Solution: Python is broken, we need to redefine arbitrary operators so I
can do this.  Approxmately 1000 extra ones should
cover all contingencies.

</mini rant>

>
> 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.
>
Better than 2 !!  At least you only butcher you copy of python ;-)

> 5. Use a customized parser in python, with some compile tools?
>
>    Advantage: can change anything.  Can fine tune before settle down.
>    Disadvantage: can change anything.  Slower than 1.  Don't know how to
use
>    it.  (But maybe they can be turned into option 1?)

Look up mxTextTools at vex.  Its not very nice to use itself, but there is a
wrapper API provided by someone else
for custom lexers/parsers.

>
> 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.
>
Adding @ and .* is an ugly hack to work around the desire to still be
writing MatLab

> 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

Umm, maybe that means something in MatLab.  Alternatively to C++ people,
it looks like you're using pointers to member functions in C++ !!

> elementwise operators might be useful elsewhere, like
>
> ["%5.2f", "%-8s", "%.2g"] .% [pi, 'short', 1]

hmm, is that the same as "%5.2f %-8s %2g" % (pi, 'short', 1).

> ["Alice", "Bob", "Charlie"] .+ "is" .+ ["girl", "boy", "boy"]
>
[does it automatically add the spaces between the words too ;-)]
yes, because
map(lambda x,y: x+"is"+y, ["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.

This is why python is not a democracy ;-)
>
> Inputs greatly appreciated.
>
>
> Huaiyu

ever-rantingly-yours,

D