[Numpy-discussion] New Operators in Python

[dpn]

With the possible inclusion of generic functions in py3k I dont really
see the point of adding more operators. (While i do miss mat1 x mat2
from PDL).

mat3 = mat1.mm(mat2) or the like seems to be sufficient.

I find matrix multiplication annoying in the case of SVD reconstruction:

final = matrixmultiply(matrixmultiply(u, s), v)

A minor gripe though. I'm more inclined to err on the side of clean
python rather than more operators, especially since aforementioned
GF's will help with many cases

dpn

On 3/26/07, Colin J. Williams <cjw at sympatico.ca> wrote:
> Charles R Harris wrote:
> >
> >
> > On 3/24/07, *Travis Oliphant* <oliphant at ee.byu.edu
> > <mailto:oliphant at 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.
> >
> >     One thing I wonder is if we are being vocal enough with the Python 3000
> >     crowd to try and get additional operators into the language itself.
> >
> >     What if we could get a few new operators into the language to help us.
> >     If we don't ask for it, it certainly won't happen.
> >     My experience is that the difficulty of using the '*' operator for both
> >     matrix multiplication and element-by-element multiplication
> >     depending on
> >     the class of the object is not especially robust.  It makes it harder to
> >     write generic code, and we still haven't gotten everything completely
> >     right.
> >
> >     It is somewhat workable as it stands, but I think it would be nicer if
> >     we could have some "meta" operator that allowed an alternative
> >     definition of major operators.   Something like @*  for example (just
> >     picking a character that is already used for decorators).
> >
> >
> > Yes indeed, this is an old complaint. Just having an infix operator
> > would be an improvement:
> >
> > A dot B dot C
> >
> > Not that I am suggesting dot in this regard ;) In particular, it
> > wouldn't parse without spaces. What about division? Matlab has both /
> > and \ for left and right matrix division and something like that could
> > call solve instead of inverse, leading to some efficiencies.
>
> Yes, thanks to a suggestion from Alan Isaac, this was implemented in
> PyMatrix (based on numarray and not yet converted to numpy). / served
> for one and // for the other.
>
> Regarding an additional multiply operator, I don't see the need for it.
>    A matrix and and array are similar dut different animals.
>
> Colin W.
>
> We also
> > have both dot and tensordot, which raises the problem of interpretation
> > when ndim > 2.
> >
> > Chuck
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at scipy.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>