[Numpy-discussion] numpy release
Christopher Barker
Chris.Barker@noaa....
Wed Apr 23 16:55:27 CDT 2008
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@noaa.gov
More information about the Numpy-discussion
mailing list