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

Penfold spam at spam.com
Wed Jul 19 20:34:41 EDT 2000


Huaiyu Zhu <hzhu at localhost.localdomain> wrote in message
news:slrn8n9s6i.so.hzhu at rock.localdomain...
> 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)?

Hmm, I dont understand the question properly.  My point is mostly that
having new operators
is fine but they'd tend to be implemented in bytecode as BINARY_DOT_ADD for
example.
Which means, what they are needs to be predefined.  Having a system where
they get dynamically created
during parsing, and could be anything, makes it hard for the byte code
compiler.  It cant generate a
BINARY_AT_DOT_HAT_ADD for a @.^+ because no such opcode exists already.  So
it would have
to instead try to call method names etc.

Which, is not that nice, especially as really, operators arent methods ;-).

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

The point is more that given a .+ b, in a piece of code, where you *dont
know* what a and b are, what is your
intuitive feel for what it should do.  I'd suggest nothing.  It could be
anything.
(As an aside, why shouldn't [1,2]+[10,20] zip the lists into [(1,10),
(2,20)]. )

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

No s/hes figured out what it does for lists, now ask them to decide what
they think x .+ y and x .* y probably do for
some arbitrary x,y.  They'll extrapolate from your example, Id hypothesis
that for other types of x and y, theyd do all sorts of weird ass stuff.

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

Matlab isnt quite a few hundred years old yet.  And why does it make the
rules?
Shouldnt we more realistically have vector/matrix operators like ||A||,
<x,y>.
These have been around a little longer ;-).

Why shouldnt the parser do unicode text, and allow me to use
intersection/union symbols so that I can
express set theortical stuff better :-)

> >[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
ack, I should read what I cut and paste ;-)

> names .+ "is" .+ types
> map(lambda x,y: x+"is"+y, names, types)
>
> 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.

Well, not strictly true.  We could make the whole thing uglier like so
map(operator.add, map(operator.add, names, ["is]*len(names)), types)

and we'd get the c speed up on the add, bypassing the slowdown from the
lambda.
But then, thats starting to look almost perlish ;-)

>
> >ever-rantingly-yours,
> >
>
> never-reply-to-rant-again-ly y'rs
>
> Huaiyu
perhaps one more time ;-)

Des.






More information about the Python-list mailing list