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[0][0]==x[0,0] is desirable.  Or so I've understood the 
>> discussion.

> I don't know why people are indexing matrices with A[x][y], but they
> shouldn't.

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 
object.

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[0][0]==x[0,0]`` **and** ``x[0]=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 
like so:

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[0][0]`` 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[0]==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 
simple, questions:

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.

-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

[EMAIL PROTECTED]
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to