There are two solutions to the A*B*C problem that are not quite comparable, and are not mutually exclusive either. 1) allow dot(A,B,C): this would be a great improvement over dot(dot(A,B),C), and it could virtually be done within a day. It is easy to implement, does not require a new syntax, and does not break BC
2) another solution, not incompatible with the first one, is to introduce a new operator in the python language. In the case that it be accepted by the python community at large (which is very unlikely, IMHO), be prepared to a very long time before it is actually implemented. We are talking about several years. I think that solution 1) is much more realistic than 2) (and again, they are not mutually exclusive, so implementing 1) does not preclude for a future implementation of 2)). Implementation of 1) would be quite nice when multiplication of several matrices is concerned. == Olivier 2009/6/7 Tom K. <t...@kraussfamily.org> > > > Olivier Verdier-2 wrote: > > > > There would be a much simpler solution than allowing a new operator. Just > > allow the numpy function dot to take more than two arguments. Then A*B*C > > in > > matrix notation would simply be: > > dot(A,B,C) > > > > with arrays. Wouldn't that make everybody happy? Plus it does not break > > backward compatibility. Am I missing something? > > > > That wouldn't make me happy because it is not the same syntax as a binary > infix operator. Introducing a new operator for matrix multiply (and > possibly matrix exponentiation) does not break backward compatibility - how > could it, given that the python language does not yet support the new > operator? > > Going back to Alan Isaac's example: > 1) beta = (X.T*X).I * X.T * Y > 2) beta = np.dot(np.dot(la.inv(np.dot(X.T,X)),X.T),Y) > > With a multiple arguments to dot, 2) becomes: > 3) beta = np.dot(la.inv(np.dot(X.T, X)), X.T, Y) > > This is somewhat better than 2) but not as nice as 1) IMO. > > Seeing 1) with @'s would take some getting used but I think we would > adjust. > > For ".I" I would propose that ".I" be added to nd-arrays that inverts each > matrix of the last two dimensions, so for example if X is 3D then X.I is > the > same as np.array([inv(Xi) for Xi in X]). This is also backwards > compatible. > With this behavior and the one I proposed for @, by adding preceding > dimensions we are allowing doing matrix algebra on collections of matrices > (although it looks like we might need a new .T that just swaps the last two > dimensions to really pull that off). But a ".I" attribute and its behavior > needn't be bundled with whatever proposal we wish to make to the python > community for a new operator of course. > > Regards, > Tom K. > -- > View this message in context: > http://www.nabble.com/matrix-default-to-column-vector--tp23652920p23910425.html > Sent from the Numpy-discussion mailing list archive at Nabble.com. > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
