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

[Tim Hochberg]

hzhu at localhost.localdomain (Huaiyu Zhu) writes:

[SNIP]

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

There is a problem with adding new operators to mean elementwise: the
current operators are already elementwise in NumPy. Either all current
NumPy code would have to be broken to fit in with this rule, or the
rule would have to become "elementwise, except when it's not", which
is somewhat less satisfying. I would suggest that it would be more
productive to add operators that are not elementwise, except that
conflicts with the rest of Python. TNSTAAFL.

Personally I think that this an overlarge crop of operators to be
adding. Since I prefer something like:

A.inv * B 

to 

A \ B

anyway, the only operator I feel is missing is the matrix
multiplication. And, conveniently, there is an appropriate opperator
already sitting around: __call__. If call were overloaded to do matrix
multiplication, then dot(A,B) (as the matrix product is written in
NumPy now) could be written:

A(B)

Similarly:

dot((A,B), C) -> A(B)(C)
dot(A, dot(B,C) -> A(B(C))

which looks pretty good to me. And it's arguably closer to paper
linear algebra notation than A*B is.

(Of course you can't do A.inv now in NumPy, but it would be relatively
simple to add).

[SNIP]

> With a little correction.  For named lists it is either
> 
> names .+ "is" .+ types
> map(lambda x,y: x+"is"+y, names, types)

There's a bit of a problem here since "is" is a sequence. I'm not sure
how you propose to have sequences of unequal length work with .X, but
I'd think this would have to be:

names .+ ["is"]*len(names) .+ types


My 12.4 cents.

-tim