[Numpy-discussion] matrix indexing question
Bill Spotz
wfspotz@sandia....
Tue Mar 27 14:28:25 CDT 2007
It seems to me that using shapes, (m,1) versus (1,n), to determine
whether a vector is column- or row-oriented is a hack (or at least
feels like one). If we know we have a vector, then we want to use a
single index to obtain a scalar, and that extra "0," or ",0"
shouldn't be necessary.
It also seems to me that there is an object-oriented design solution
to this, namely defining column_vector and row_vector classes that
inherit from matrix, that accept a single index, but behave as
matrices consistent with their type. I'm sure there are implications
to this I haven't thought through yet, but at least it gives us
logical indexing AND persistence of matrices through operations.
On Mar 27, 2007, at 1:11 PM, Travis Oliphant wrote:
> Thanks for listing your points. I can see that this is an issue
> where
> reasonable people will disagree because there are multiple ways of
> looking at it.
>
> The idea that matrix selection would return matrices really comes from
> wanting to keep matrices more persistent through operations.
>
> M[0] could be seen either as a 1xn matrix or a n-length array. I
> agree that both concepts are possible. Seeing it as a 1xn matrix
> allows
> matrices to remain persistent more often.
>
> So, the arguments for the current approach and the arguments
> against it
> to me seem on the same level, so I don't see a reason to change the
> current behavior and see a lot of strong reasons not to change the
> behavior (we are in a 1.0 release and could not change anything
> until at
> least 1.1 anyway).
>
> With that said:
>
> One of my goals for the next year or two is to create a matrix
> class in
> C and incorporate CVXOPT matrices and it's coupled sparse
> matrix. We
> can re-visit this question in that process. I would like for there to
> be a sparse matrix implementation in NumPy (without the solver which
> will remain in SciPy).
>
> But, the sparse matrix and the matrix need to have the same behaviors
> and should be able to interoperate with each other.
>
> So, if you would like to help with that project all input is welcome.
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-5451 **
** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
More information about the Numpy-discussion
mailing list