[Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Alan G Isaac wrote:
> For useful reference, these are now here:
> <URL:http://www.scipy.org/MatrixIndexing#guidelines>

Thanks Alan, Here are a few comments on that text (I know, I really 
should go dig up my scipy password...)

 >   1. Do we want to be able to extract a single row or column from a
 > matrix, and have it be indexable like a 1-d object? (Answer: 
certainly > yes for rows, but columns could be gotten from the transpose.

I don't get this -- transpose of what? if you get a 1-d ndarray from:
M[i,:], that can't be transposed -- it's 1-d. You could do M.T[0] but 
then you've lost the concept of it being a column. If we stick with 
M[i,:] being a (n,1) matrix, then  it doesn't index like a 1-d object, 
and it doesn't need transposing anyway.

 > This is most useful, allows the most generic code, and breaks fewest
 > expectations.)

 >   2. Do we want to be able to do (1) without calling the Array
 > attribute: M.A[i]? (Yes: this is not less useful, allows the most
 > generic code, and breaks fewest expectations.)

 >   3. Do we want to have those 1-d objects to have an orientation so
 > that they act like Row or Column vectors in linear algebra operations
 > (and broadcasting)? (Unclear: the resulting functionality could be
 > provided by rows and columns attributes that yield corresponding
 > matrices.)

no, it couldn't -- we can already use M[:,i] (or M[:,i:i+1] to get a 
matrix that is essentially a column -- however that can't be indexed 
with a scalar (see (1). That's kind of the point of this discussion. Or 
did you mean that you get a column by: np.matrix(M[:,i]).T ? yow!


Maybe we need to separate the row and column questions -- particularly 
with Charles' discovery of how other parts of numpy expect rank 
reduction with indexing, I think we probably have a consensus that we 
need to be able to extract 1-d objects from matrixes with indexing -- at 
least rows.

That leaves the column question: -- do we need an object that represents 
a column, that otherwise acts like a 1-d array (returns a scalar with 
scalar indexing)?

I guess my key point is that the fact that seeing a Matrix as a 
collection of rows rather than columns is an accident of C memory 
arrangement -- if numpy (and python) had been written in Fortran, we'd 
have the opposite. I'd rather that not be built into the API more than 
required. We can only have one definition for M[i], it might as well be 
a row, but other than that, we can have symmetry:

M[i,:] is row
M[:,i] is a column

and rows and columns behave the same way everywhere they "should": 
indexing, converting to ndarrays, ???, but not in linear algebra operations.

Then, or course there are implementation details...


-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov