[Numpy-discussion] matrix indexing question

[Charles R Harris]

On 3/29/07, Bill Spotz <wfspotz at sandia.gov> wrote:
>
> What I envisioned was that M[i,:] would return a row_vector and M
> [:,j] would return a column_vector, because this would be symmetric
> behavior.  M[i], by convention, would behave the same as M[i,:].
>
> But then I personally don't distinguish between "python indexing" and
> "numpy indexing".  In both cases, __getitem__() (or __setitem__()) is
> called.  For multiple indexes, the index object is a tuple.
>
> In any case, the behavior of "numpy indexing" as I have proposed it
> would return an object that inherits from matrix, thus would BE a
> matrix, although it would behave like an array.


I'm thinking that a basic problem is not having row and column types
distinct from matrices. Column types would represent elements of a vector
space and row types elements of the dual, they would both be 1-dimensional.
One could go full bore with tensors and index signatures, upper and lower,
but I think plain old matrices with the two vector types would solve most
ambiguities. Thus if v were a column vector, then v.T*v would be a scalar
where the product in this case is shorthand for v.T(v). Likewise,
v*v.Twould be a matrix (in tensor form the indices would be upper
lower
respectively, but ignore that). The default translation of a normal 1-D
vector would preferably be a column vector in this case, opposite to current
usage, but that is not really crucial. Note that nx1 and 1xn matrices are
not quite the same thing as column and row vectors, as the latter would
normally be considered linear maps and v.T*v would return a scalar matrix,
quite a different thing from a scalar.

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