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 <[EMAIL PROTECTED]> wrote: > Charles R Harris wrote: > > > > > > On 3/24/07, *Travis Oliphant* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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@scipy.org > > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
