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

[Huaiyu Zhu]

On Tue, 18 Jul 2000 23:35:30 +0100, Penfold <spam at spam.com> wrote:

>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 ;-)

Hmm, so I see the issue - an operator is supposed to do a lot of things, all
of which expressed as an opcode (or whatever BINARY_ADD is called).  This
opcode is only available in the C source, so there is no direct pathway to
go from .* to __dotmul__ purely inside python.

Let's see what happens to a class, which also can do a lot of things, but
all of them are available within python.  Why?  Because the internal things
are in __dict__.

So why isn't there be something like a __dict__ that holds all the
properties of operators, including opcode?  Maybe because operators are not
supposed to change any way?  Maybe because this stage is even lower than the
implementation of dictionary?  Or is there more fundamental technical
reasons (Like making the compiler much slower)?

><mini rant>

I know I'm not supposed to respond to rant, but this has come up many times
so I thought I might just do it once and for all.

[ about + - * / being easily understandable but no clue about additional
operators which have no implicit meaning]

The implicit meaning is "the dot in front means the operator is
elementwise".  Tell a newbie this, then show him the following piece of code

[1,2] + [10,20] == [1,2,10,20]
[1,2] .+ [10,20] == [11, 22]

Then give him two minutes for brainstorming. He probably will figure out
what .* .- ./ do.

>But why stop here, why not proliferate the language with #!'s. Hell, I want
>python to be more like perl,

I have posted another article dealing with comparison with perl.  It hasn't
come up yet.  I may repost it.

>    Problem: Why do I have to write x.sendMessage(y.createMessage(txt))?  I
>should be able to write x &^% (y *&^ txt)

Well the problem is not with additional operators, but with the symbols you
choose to represent them.  The effect is similar if you write

x.adadsfsfdasf(y.cuaiouaoiu(txt))

You are allowed to do so in python. It wouldn't be Python's responsibility
if You actually do it.  Why would it make Python any worse if it allows you
to do the other thing and You actuall do it?

The best way to choose a meaningful symbol in your field is to use the ones
people have used for hundreds of years, or if your field hasn't existed that
long, spell things out explicitly.  It is a general rule that the newer the
field, the more verbose the names.  When things settle down the notations
will become more concise.  When the total number reduces to less than 7 :-)
you could even start to consider using binary operators if all of them have
a simple rule that maps to existing arithmetic operators that a newbie
understands in two minutes.  

>
></mini rant>

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

Please if some one can figure out how to use it to accept .+ as operator and
use __dotadd__ to define it.  After that I think I can figure out the rest.
:-)

>> 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).
>
No.  The result is a list.

>> ["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"])

With a little correction.  For named lists it is either

names .+ "is" .+ types
map(lambda x,y: x+"is"+y, names, types)

Whichever is deemed cleaner, I suppose there really is no need for list
comprehension after all.

The probelm is, of course, you cannot make a C module to speed up
elementwise operations with the latter notation because it uses builtin
syntax rather than method call.

>ever-rantingly-yours,
>

never-reply-to-rant-again-ly y'rs

Huaiyu