[Numpy-discussion] matrix indexing question

[Charles R Harris]

On 3/29/07, Timothy Hochberg <tim.hochberg at ieee.org> wrote:
>
> """matrix.py
>
> The discussion about matrix indexing has been interminible and for
> the most part pretty pointless IMO. However, it does point out one
> thing: the interaction between the matrix and array classes is still
> pretty klunky despite a fair amount of effort trying to make them
> interoperate.
>
> Here's one possible alternative approach to enabling matrix operations
> within the context of numpy arrays. I started with a few requirements:
>     1. Matrices should be proper subclasses of arrays in the sense
>        that one should be able to use matrices wherever one uses
>        arrays with no change in the result.
>     2. Indexing into matrices should produce row or column vectors
>        where appropriate.
>     3. There should be some syntax for matrix multiplication. I
>        know that there are other operations defined on the matrix
>        class, but I don't consider them worth the headache of
>        having two class hierarchies.


<snip>


>
> Note, however that you can't (for instance) multiply column vector with
> a row vector:


Well, let's carry this to extremes. Strictly speaking, from the functional
point of view, (r)(c) == (c)(r), the dual of the dual is the original vector
space, for finite dimensional spaces anyway. However, custom reserves the
latter form for the tensor product, and so that is probably a good thing to
keep. However, to really make the transpose operate correctly it should also
conjugate. This could just be a flag in the row vector, no changes in the
data needed, but vdot would be called instead of dot when computing (c.t)(c).
A similar thing could be done for matrices if vdot were extended to deal
with matrices -- currently it only works for scalars and vectors. Now,
products like (c.t)(M.t) would need to conjugate/transpose both, but this
could be computed as ((M)(c)).t. So on and so forth. A lot of these types of
operations are in BLAS, IIRC, so in some sense this is just a mapping to
BLAS.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070330/ee16efa0/attachment.html>