[Numpy-discussion] numpy release

[Christopher Barker]

Alan Isaac wrote:
> I have updated <URL:http://www.scipy.org/MatrixIndexing>
> to reflect this change (and its provisional status).

Thanks for writing this up -- it really clarifies what's being proposed. 
A few comments on that write up:

 > For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the array
 > attribute of a Row Vector or Column Vector be 1d?

Absolutely -- a vector is a 1-d array. The only difference here is that 
we can preserve the concept of a row vs. a column vector -- key to 
linear algebra, which is the whole point of the Matrix class. I'd be 
just as happy if a RowVector an ColumnVector were a more unique object 
-- a 1-d array with the operation overloaded, rather than a (1,n) or 
(n,1) matrix, but I understand that would be more work.

 > Deviations from the behavior of ndarrays. Specifically, iteration over
 > a matrix will not yield 1d NumPy arrays.

Why should they? indexing a nested list gives a different result than 
indexing an ndarray, etc, etc, etc. The POINT of matrixes is that they 
are different! This proposal makes them a little more similar to 
ndarrays than the old behavior (always returning a matrix).

 > Inconsistency in the indexing style for producing row vectors and
 > column vectors

not really:

row vector: M[i,:]
column vector: M[:,i]

The fact that there is another way to get a row vector: M[i] is a bonus. 
I once proposed making M[i] raise an exception for the sake of enforcing 
consistency, but no one liked that!

 > Loss of a standard way to extract a row or a column as a submatrix
 > (rather than a vector)

What's wrong with:

M[i:i+1, :] and M[:, i:i+1]

This is totally consistent with arrays (and other python sequences). 
Yes, it's a bit more awkward, but with the new vectors, it's also going 
to be needed far less.

 > No clear gain in functionality over the simpler proposal 2.

Well, I won't judge what's "clear" but I think this adds functionality. 
The concept of row and column vectors is a key part of linear algebra. 
Sure, you can model them as matrixes that happen to have only one row or 
one column, but that's what we had, but there seem to be real issues 
with use of that. Option (2), is "Let a Matrix be a container of 1d 
arrays.". Sounds simple, but do those arrays represent row or column 
vectors? Either would make sense. The proposal is for them to be row 
vectors, which is fine, but then if you want them to act like a row 
vectors, do you need to convert them back into matrices? Even if not, 
how do you get a column vector -- by indexing the current way, and 
getting a (n,1) matrix, so that now we have inconsistency between how 
row and column vectors are treated -- not a clean API.

And this is about a clean API for linear algebra -- otherwise, we'd just 
all use arrays (which many do!)

Aside from the fact that someone needs to write the code -- why don't 
people like the row/column vector idea? It just feels so natural to me:

A matrix is a 2-d array with some functionality overloaded to make it 
convenient to do linear algebra.

A vector is a 1-d array with some functionality overloaded to make it 
convenient to do linear algebra.

A scalar is the same in both contexts, so no need to change anything there.

And yes, maybe this will lead to tensors some day!

Another couple questions: -- would there be constructors for vectors?

np.RowVector((1,2,3,4,5))
np.ColumnVector((1,2,3,4,5,6))

and would:
A_RowVector.T == A_ColumnVector

I would think so.

One more note:

All the example code I've seen during this discussion have been examples 
of iterating and indexing -- not one has actually been linear algebra -- 
perhaps we should see some of those before making any decisions.

-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 at noaa.gov