[SciPy-dev] New Operators in Python

Bill Baxter wbaxter@gmail....
Fri Mar 23 19:54:35 CDT 2007

On 3/24/07, Travis Oliphant <oliphant@ee.byu.edu> wrote:
> Every so often the idea of new operators comes up because of the need to
> do both "matrix-multiplication" and element-by-element multiplication.
> I think this is one area where the current Python approach is not as
> nice because we have a limited set of operators to work with.

I would probably use such operators if they existed.  But I think it
will be an uphill battle.  Where else is there a pressing need for
more operators besides Numpy?  I agree that the current situation
makes it very tedious to get things right when there's a mix of matrix
and array in the code.  It basically makes it so you can't use * at
all, since you can't be sure which version you'll get.  Or you have to
asarray() or mat() everything just to be sure.  But at that point just
doing dot(a,b)  to force matrix multiply (or multiply() to get
elementwise) looks not much worse.

I don't mind the occasional dot(a,b) here and there, actually.  That's
pretty readable.  But as soon as you have 3 or more terms it gets
ugly.  dot(a,dot(b,c)) is just not as easy to read as (a * b * c).

I think it would be nice if dot could take more than one argument.
dot(a,b,c) wouldn't be bad.  I seem to recall someone looked into
that, though, and the fact that dot will take a 1-d array and treat it
as either a row or a column made the result ambiguous in some cases.
It seems though like that shouldn't be a show stopper.  Just say that
the interpretation is done greedily from left to right, so that
dot(a,b,c,d) has the same meaning as dot(dot(dot(a,b),c),d).

As a further extension, to control ordering, dot could also accept
plain sequences, so dot(a,(b,c)) would dot(b,c) first.

For me, those sort of changes would go a long way towards making life
without extra operators bearable.


More information about the Scipy-dev mailing list