[Numpy-discussion] untenable matrix behavior in SVN
Mon Apr 28 14:02:57 CDT 2008
Gael Varoquaux wrote:
> On Fri, Apr 25, 2008 at 01:40:29PM -0400, Alan G Isaac wrote:
>> In contrast, there *is* universal agreement that
>> x==x[0,0] is desirable. Or so I've understood the
> I don't know why people are indexing matrices with A[x][y], but they
I think there has been a misunderstanding here. I don't think anyone is
suggesting that if a coder wants an element of a matrix, that s/he
should write that:
element = M[i,j]
Rather, that one might want to extract a row from a Matrix, and then
index THAT object with a scalar:
row = M[i]
now do something with each element in that row: something = row[j]
This is a rational, normal thing to do, and I think the desire for this
is the core of this entire discussion, coming from the fact that in the
current version of matrix both of M[i] and M[i,:] yield a matrix, which
is 2-d, and cannot be indexed with a scalar. This is odd, as it is
pretty natural to expect a single row (or column) to behave like a 1-d
Alan G Isaac wrote:
> I believe that this conflicts with submatrix extraction.
> If we want to keep submatrix extraction (as we should),
why? with 2-d arrays, you get a subarray with:
A[i:j,:] and a 1-d array with A[i,:] -- why does that need to be
different for Matrices?
> 3. If ``v`` is a "RowVector" what behavior do we get?
> Suppose the idea is that this will rescue
> ``x==x[0,0]`` **and** ``x=x[0,:]``.
> But then we must give up that ``x[0,:]`` is a submatrix.
Correct, but why should it be -- we can get a submatrix with slicing, as
above. Indeed, I was about to post this comment the other day, as
someone was concerned that there needs to be a distinction between a
ColumnVector and a Matrix that happens to have a second dimension of one.
I think that the Vector proposal satisfies that:
if you have code like:
SubMatrix = M[i:j, k]
Then you will always get a SubMatrix, even if j == i+1. If you index
Vector = M[i,k] you will always get a vector (a 1-d object)
> Must ``v`` deviate from submatrix behavior in an important way?
> Yes: ``v`` is an IndexError.
Correct, but if you're writing the code that generated that vector,
you'd know it was a 1-d object.
> Since submatrix extraction is fundamental, I think it is
> a *very* bad idea to give it up.
I agree -- but we're not giving it up, what we are doing is making a
distinction between extracting a single row or column, and extracting a
submatrix (that may or may not be a single row or column) -- just like
that distinction is make for regular old ndarrays.
> RowVector proposal we must give up ``x==x[0,:]``.
> But this is just what we give up with
> the much simpler proposal that ``v`` be a 1d array.
no, we also give up that v acts like a row or column (particularly
column) vector in computation (*, **)
We still need real linear algebra computation examples....
Alan G Isaac wrote:
> I weight the future more heavily. We are approaching a last
> chance to do things better, and we should seize it.
Yes, but it seems that while a consensus will not be reached in time for
1.1, there is one that a change will probably occur in the next version,
so there is a lot to be said for waiting until a proposal is settled on,
then make the whole change at once.
> The right questions looking forward:
> - what behavior allows the most generic code?
> - what behavior breaks fewest expectations?
> - what behavior is most useful?
Yes, but I'm going to try to put down what I think are the key, very
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?
2) Do we want to be able to do that without having to explicitly call
the Array attribute: M.A[i]?
3) Do we want to have those 1-d objects act like Row or Column vectors
in linear algebra operations (and broadcasting)?
4) Do we want to require slice notation to get a submatrix that happens
to have a single row or column?
If we want (1) and (2), then we need to make a change. If we want (3)
and (4), then something like the Row/ColumnVector proposal is needed.
I really think it's that simple.
Christopher Barker, Ph.D.
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
More information about the Numpy-discussion