[Numpy-discussion] New Operators in Python
Sun Mar 25 10:08:41 CDT 2007
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
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
On 3/26/07, Colin J. Williams <email@example.com> wrote:
> Charles R Harris wrote:
> > On 3/24/07, *Travis Oliphant* <firstname.lastname@example.org
> > <mailto:email@example.com>> 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
> > Numpyfirstname.lastname@example.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> Numpy-discussion mailing list
More information about the Numpy-discussion