# [Numpy-discussion] matrix default to column vector?

Olivier Verdier zelbier@gmail....
Sun Jun 7 08:51:55 CDT 2009

```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. <tpk@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
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090607/4414815b/attachment-0001.html
```