Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

> 2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
>>  I must have misunderstood:
>>  I thought the agreement was to
>>  provisionally return a 1d array for x[0],
>>  while we hashed through the other proposals.

On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> The agreement was:
> a) That x[0][0] should be equal to x[0,0] and 
> b) That x[0,:] should be equal to x[0] (as for ndarrays)

1. This is **not** what I understood as the agreement
(and I think the current solution is bad).
I certainly did not mean to support the change that
as implemented, and it is not clear to me that others
did either.

2. These two goals are substantially in conflict for 
matrices, as we are seeing.

3. The important goal, (goal a., which everyone agrees on),
has NOT been accomplished by the current change:
x[0][0] raises a TypeError when x is a 1 by N matrix.


> This breaks as little functionality as possible, at the 
> cost of one (instead of two) API changes. 

I cannot agree with this assessment.

> the current situation is not tenable. 

I agree with this!  Better than the SVN behavior would be to 
raise an error in response to scalar indexing of matrices.
I strongly hope that this behavior will not show up in 
a release!

Please return 1d arrays in response to scalar
indexing as the provisional arrangement.
This is certainly better than the new behavior.

Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Fri, 25 Apr 2008, Jarrod Millman apparently wrote:
> I would like, so I can't tell if there is anything so 
> uncontroversial that it would make sense to change for the 
> 1.1.0 release.

I think it is clear from reactions that the revision r5072 
to matrix behavior should NOT go into any release.

> If there is something that can be unanimously agreed on 
> within the next 24 hours or so, I would be happy to have 
> it included in 1.1.


I see 3 possibilities (in rank order of preference):

1. return 1d arrays in response to scalar indexing of matrices
2. raise an error on scalar indexing of matrices
3. simply revert the r5072 change.

Since there is universal accord that x[0][0] == x[0,0] is 
desirable, and we will get that with option 1, I think it is 
the right provisional behavior.  I believe that option 
1 provides a step in the direction of the ultimate behavior,
no matter what that will be.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Stéfan van der Walt]

2008/4/25 Alan G Isaac <[EMAIL PROTECTED]>:
>  1. This is **not** what I understood as the agreement
>  (and I think the current solution is bad).

Reverted in r5084.

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Fri, 25 Apr 2008, Stéfan van der Walt wrote:
> workaround would break x[0] == x[0,:] 


But there is not universal agreement that x[0] == x[0,:] is 
desirable.  In contrast, there *is* universal agreement that
x[0][0]==x[0,0] is desirable.  Or so I've understood the 
discussion.

As you know, my view is that nonscalar indexing should
return submatrices, while scalar indexing should return
1d arrays.  Thus I do not see  x[0] != x[0,:] as breakage:
it is desirable.  Indeed, without it, we will have an
untenable situation, under all the different proposals.
So it is a goner one way or another.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> Reverted in r5084. 

Thank you.

I think we have discovered that there is a basic conflict 
between two behaviors:

x[0] == x[0,:]
vs.
x[0][0] == x[0,0]

To my recollection, everyone has agree that the second 
behavior is desirable as a *basic expectation* about the
behavior of 2d objects.  This implies that *eventually* we 
will have ``x[0][0] == x[0,0]``.  But then eventually
we MUST eventually have x[0] != x[0,:].

Since a current behavior must disappear eventually, we 
should make it disappear as soon as possible: before the 
release.  The question is how.  I see two simple ways to 
move forward immediately:

1. scalar indexing of matrices returns a 1d array
2. scalar indexing of matrices raises a TypeError

If we raise a TypeError, we lose both behaviors.
If we return a 1d array, we retain the behavior
that has been seen as desirable (as a *basic expectation* 
about the behavior of 2d objects).

Stefan, do you agree, and if so, would you be willing to 
have a vote on these two options?

Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Fri, Apr 25, 2008 at 12:02 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:

> On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> > Reverted in r5084.
>
> Thank you.
>
> I think we have discovered that there is a basic conflict
> between two behaviors:
>
>x[0] == x[0,:]
>vs.
> x[0][0] == x[0,0]
>
> To my recollection, everyone has agree that the second
> behavior is desirable as a *basic expectation* about the
> behavior of 2d objects.  This implies that *eventually* we
> will have ``x[0][0] == x[0,0]``.  But then eventually
> we MUST eventually have x[0] != x[0,:].
>
Choices:

1) x[0] equiv x[0:1,:] -- current behavior
2) x[0] equiv x[0,:] -- array behavior, gives x[0][0] == x[0,0]

These are incompatible. I think 1) is more convenient in the matrix domain
and should be kept, while 2) should be given up. What is the reason for
wanting 2)? Maybe we could overload the () operator so that x(0) gives 2)?
Or vice versa.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

On 25/04/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Apr 25, 2008 at 12:02 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > I think we have discovered that there is a basic conflict
> > between two behaviors:
> >
> >x[0] == x[0,:]
> >vs.
> >
> >x[0][0] == x[0,0]
> >
> > To my recollection, everyone has agree that the second
> > behavior is desirable as a *basic expectation* about the
> > behavior of 2d objects.  This implies that *eventually* we
> > will have ``x[0][0] == x[0,0]``.  But then eventually
> > we MUST eventually have x[0] != x[0,:].
> >
> Choices:
>
> 1) x[0] equiv x[0:1,:] -- current behavior
> 2) x[0] equiv x[0,:] -- array behavior, gives x[0][0] == x[0,0]
>
> These are incompatible. I think 1) is more convenient in the matrix domain
> and should be kept, while 2) should be given up. What is the reason for
> wanting 2)? Maybe we could overload the () operator so that x(0) gives 2)?
> Or vice versa.

We are currently operating in a fog of abstraction, trying to decide
which operations are more "natural" or more in correspondence with our
imagined idea of a user. We're not getting anywhere. Let's start
writing up (perhaps on the matrix indexing wiki page) plausible use
cases for scalar indexing, and how they would look under each
proposal.

For example:

* Iterating over the rows of a matrix:

# array-return proposal; x is a scalar
for row in M:
if np.all(row==0):
raise ValueError
# exception-raising proposal
for i in xrange(M.shape[0]):
if np.all(M[i,:]==0):
raise ValueError

Other applications?

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Alan G Isaac wrote:
> Please return 1d arrays in response to scalar
> indexing as the provisional arrangement.

+1 (for the provisional solution)

This has clarified it a bit for me. The current situation allows one to 
create "row vectors" and "column vectors" by generating matrices (in 
various ways) that happen to be shape (1,n) or (n,1). These objects 
behave as we all want in arithmetic operations (*, **). So what's missing:

*
The ability to index one of these "vector" objects by a single index, 
and get a scalar as a result.
*

If I'm not mistaken (and I probably am) -- that is the crux of this 
entire conversation.

Do we want that? I would say yes, it's a pretty natural and common thing 
to want.

Note that with the current version of matrix (numpy 1.1.0rc1), you can 
index a (n,1) matrix with a scalar, and get a (1,1) matrix, but you get 
an exception if you try to index a (1,n) matrix with a scalar:

 >>> rv
matrix([[3, 4, 5]])
 >>> rv[1]
Traceback (most recent call last):
   File "", line 1, in 
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/defmatrix.py",
 
line 228, in __getitem__
 out = N.ndarray.__getitem__(self, index)
IndexError: index out of bounds

I know why that's happening, but I think it's a demonstration of why we 
might want some sort of "vector" object, for a cleaner API.

How do we achieve this?

One possibility is to special case (n,1) and (1,n) matrices, but I think 
there is consensus that that is a BAD IDEA (tm)

Which leaves us with needing a "vector" object -- which acts a lot like 
a 1-d array, except that it acts like a (n,1) or (1,n) matrix with * and 
**, and may get printed differently.

I think there are two ways to accomplish this:
   (1) RowVector or ColumnVector objects that are essentially 1-d 
ndarrays, with a few methods overridden.

   (2) A Vector object that is a matrix of either (n,1) or (1,n) in 
shape, with a couple methods overridden.

I think the difference is an implementation detail. They should behave 
about the same either way.

In either case, we should probably have factory functions for these 
objects: RowVector() and ColumnVector()

By the way, I think this brings us closer to the goal of matrices 
"acting as much like arrays as possible" -- when you index into a 2-d 
array:  A[:,i], you get a 1-d array. These "vectors" would act a lot 
like 1-d arrays, so that would be more similar than the current situation.

It also might be nice to have iterators over rows and columns, like:

for row in M.rows:
   ...
and
for col in M.columns:
   ...

We can get the rows as the default iterator, but it feels nice and 
symmetric to be able to iterate over columns too (though I have no idea 
how useful that would really be)

Stéfan van der Walt wrote:
> The whole idea of matrices was that you always
> work with 2-dimensional arrays, even when you just extract a row.
> Unless you have a proper hierarchical container (as illustrated in the
> other patch I sent), returning a 1D array breaks at least some
> expectation.

I agree -- stopgap is OK (but having people do M.A[i] is a fine stopgap 
too), but if we really want this, we need some sort of "vector" object.

 > If that's what the matrix users want, though, then we
> should change it.

I still want to see some linear algebra examples -- that's what matrices 
are for. We can iterate over 2-d arrays and get 1-d arrays just fine 
now, if that's what you want.

> Unless we agree on something, and soon, that won't happen.  Your
> workaround would break x[0] == x[0,:], so we're just swapping one set
> of broken functionality for another.

Alan G Isaac wrote:
> But then we MUST eventually have x[0] != x[0,:].

I don't think so -- I think a Vector object would allow both of:

M[i,j] == M[i][j]
and
M[i] == M[i,:]

however,

M[i] != M[:,i] -- M[i] can only mean one thing, and this doesn't hold 
for arrays, either.

and (if we do the iterators):

M.rows[i] == M[i,:]
M.columns[i] == M[:,i]

You can get rows a bit more conveniently than columns, which is really 
just an accident of how C arranges memory, but why not? Again, to make 
this "pure" we'd disallow M[i], but practicality beats purity, after all.

> how would you
> index into a vector (as in http://en.wikipedia.org/wiki/Vector_(spatial)) 
> without it?

Right -- which is why a 1-d "vector" object has its uses.

Alan G Isaac wrote:
> Since a current behavior must disappear eventually, we 
> should make it disappear as soon as possible: before the 
> release.  The question is how.  I see two simple ways to 
> move forward immediately:
> 
> 1. scalar indexing of matrices returns a 1d array
> 2. scalar indexing of matrices raises a TypeError

I don't agree -- what we have is what we have, not changing it will not 
break any existing code, so we should only make a change if it moves us 
closer to what we want in the future -- it does seem that most folks do 
want M[i] to return some sort o

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Fri, 25 Apr 2008, Christopher Barker apparently wrote:
> I think a Vector object would allow both of:
> M[i,j] == M[i][j] 
> and 
> M[i] == M[i,:] 

The problem is that it would be a crime to give up
the natural production of submatrices.   The NATURAL RULE
is: to get a submatrix, use nonscalar indices.
We should *not* give up that x[0,:] is a sub*matrix*
whose first element is x[0,0] and equivalently x[0][0].
*This* is why we must have x[0]!=x[0,:] if we want,
as we do, that x[0][0]==x[0,0].

Note that the idea for attributes ``rows``
and ``columns`` is contained on the discussion page:
http://www.scipy.org/MatrixIndexing>
I claim that it is natural for these attributes
to yield properly shaped *matrices*.
Once we have these attributes, it is difficult to
see what we gain by introducing the complication
of a separate vector class.

I still see no real gain from a separate vector class
(or row and column vector classes).
Everything that has been proposed to do with these
is achievable with the corresponding matrices with
one exception: scalar indexing -> element so that
x[0][0]==x[0,0].  But this outcome is achieved
MUCH more simply by letting x[0] be a 1d array.

Anyway, I am glad you agree that letting ``x[0]`` be a 1d 
array is the proper provisional solution.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Fri, Apr 25, 2008 at 2:57 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:

> On Fri, 25 Apr 2008, Christopher Barker apparently wrote:
> > I think a Vector object would allow both of:
> > M[i,j] == M[i][j]
> > and
> > M[i] == M[i,:]
>
> The problem is that it would be a crime to give up
> the natural production of submatrices.   The NATURAL RULE
> is: to get a submatrix, use nonscalar indices.
> We should *not* give up that x[0,:] is a sub*matrix*
> whose first element is x[0,0] and equivalently x[0][0].
> *This* is why we must have x[0]!=x[0,:] if we want,
> as we do, that x[0][0]==x[0,0].
>

I would give it up and let x(0) be a submatrix, the normal indexing is then
exactly like an array. True, the result of x(0) can't be used as an lvalue
(only getitem equivalence), but otherwise it should work fine.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

>> On Fri, 25 Apr 2008, Christopher Barker apparently wrote:
>>> I think a Vector object would allow both of:
>>> M[i,j] == M[i][j] 
>>> and 
>>> M[i] == M[i,:] 


> On Fri, Apr 25, 2008 at 2:57 PM, Alan G Isaac 
> <[EMAIL PROTECTED]> wrote:
>> The problem is that it would be a crime to give up 
>> the natural production of submatrices.   The NATURAL RULE 
>> is: to get a submatrix, use nonscalar indices. 
>> We should not give up that x[0,:] is a sub*matrix* 
>> whose first element is x[0,0] and equivalently x[0][0]. 
>> This is why we must have x[0]!=x[0,:] if we want, 
>> as we do, that x[0][0]==x[0,0]. 


On Fri, 25 Apr 2008, Charles R Harris apparently wrote:
> I would give it up and let x(0) be a submatrix, the normal 
> indexing is then exactly like an array. True, the result 
> of x(0) can't be used as an lvalue (only getitem 
> equivalence), but otherwise it should work fine. 

The "it" here is ambiguous.
Which do you want to give up?

- x[0][0]==x[0,0] ?
  the argument has been that this is a fundamental
  expectations for 2d array-like objects, and 
  I think that argument is right

- x[0]==x[0,:] ?
  I believe you mean we should give this up,
  and if so, I strongly agree.  As you know.
  Enforcing this is proving untenable and costly.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Fri, Apr 25, 2008 at 01:04:53PM -0400, Alan G Isaac wrote:
> On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> > The agreement was:
> > a) That x[0][0] should be equal to x[0,0] and 
> > b) That x[0,:] should be equal to x[0] (as for ndarrays)

> 1. This is **not** what I understood as the agreement
> (and I think the current solution is bad).
> I certainly did not mean to support the change that
> as implemented, and it is not clear to me that others
> did either.

> 2. These two goals are substantially in conflict for 
> matrices, as we are seeing.

> 3. The important goal, (goal a., which everyone agrees on),
> has NOT been accomplished by the current change:
> x[0][0] raises a TypeError when x is a 1 by N matrix.

I claim b is more important than a. IMHO, a is plain wrong: you should't
be indexing x with x[0][0]. I am OK making a work, as long as it doesn't
break b. In addition breaking be is backward incompatible changes for no
good reason (replacing one missfeature with another).

I would like this issue addressed in next release, not this one. I have
the feeling the discussion is not sane enough, right now.

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Fri, Apr 25, 2008 at 01:40:29PM -0400, Alan G Isaac wrote:
> On Fri, 25 Apr 2008, Stéfan van der Walt wrote:
> > workaround would break x[0] == x[0,:] 


> But there is not universal agreement that x[0] == x[0,:] is 
> desirable.  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 AGREE! Sorry for yelling, but I don't see where you get your
universality. You want to break backward incompatibility to accomodated
wrongful indexing, and break rightful indexing. 

I don't know why people are indexing matrices with A[x][y], but they
shouldn't. We have multidimensional objects, and a lot of effort has been
put in that. Indexing with one dimension only is poor amongst other
things for performance reasons. We also see that it breaks indexing
semantics and fobrid doing clever indexing. That cannot be worked around,
because by indexing with one dimension you are putting less information
into the indexing routine than by indexing with two dimension.

> Thus I do not see  x[0] != x[0,:] as breakage:
> it is desirable. 

You may think what you want. We may desagree on what is Right, but the
breaks backward compatibility, and thus is a breakage and should be given
a lot of thought.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> I claim b is more important than a. IMHO, a is plain 
> wrong: you should't be indexing x with x[0][0]. 


Why?? Would you say this about a 2d array?
Why the difference?

The core argument has been that it is a **basic 
expectation** of the behavior of 2d array-like objects that 
you will be able to get, e.g., the first element with x[0][0].
(E.g., lists, tuples, arrays ... is there an exception??
It should not be broken!)

I teach with matrices and I thought you might too: if so, 
you surely have run into this expectation (which is **natural**).
In fact I truly doubt anyone has not been puzzled on first 
encounter by this::

>>> x
matrix([[1, 2],
[3, 4]])
>>> x[0]
matrix([[1, 2]])
>>> x[0][0]
matrix([[1, 2]])

Another argument, which I agree with, has been that matrix 
behavior should match 2d array behavior except where there 
is a clear payoff from deviation.

What I do agree with, which I take to be implicit in your 
statement, is that if users of matrices should generally use 
multiple indexes.  But that does not answer the question 
about what we should offer when x[0] is requested.
(Or, more crucially, what you get when you iterate over
a matrix.)

Cheers,
Alan Isaac

PS If you have good arguments, please add them to
http://www.scipy.org/MatrixIndexing>



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> I don't see where you get your universality. 

Lists, tuples, arrays ...
Where is the exception?
Only matrices are the only 2d container I can
think of that are broken this way.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> We may desagree on what is Right, but the breaks backward 
> compatibility, and thus is a breakage and should be given 
> a lot of thought. 


I agree with this.  I am a matrix user, and I have given it 
a lot of thought.  I have been making this case for a *long* 
time.  It has come to a head because of the announced desire 
to severely constrain API changes moving forward.

As I am best able to understand you abstract view, the right 
thing to do would be for matrices to raise an error in 
response to a scalar index.  However, I deduce, you would 
just leave things alone to avoid backward incompatibility.

I weight the future more heavily.  We are approaching a last 
chance to do things better, and we should seize it.

The right questions looking forward:

- what behavior allows the most generic code?
- what behavior breaks fewest expectations?
- what behavior is most useful?

Cheers,
Alan Isaac

PS I cannot recall: do you use matrices?


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 11:13:12AM -0400, Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> > I claim b is more important than a. IMHO, a is plain 
> > wrong: you should't be indexing x with x[0][0]. 


> Why??

Because a 2D object is not a list of list. It is more than that. The
numpy array actually exposes this interface, but I think using it
systematicaly when it is not required is abuse. Moreover you are creating
temporary objects that are useless and harmful. They are harmful for
performance: you have to create useless objects and call their
__getitem__ functions. 

> Would you say this about a 2d array?

Of course. Even more. Suppose you have an nd array, with n=10, to index
object using 10 different indexing, ie A[a][b]... you have to create 9
intermediate objects that get indexed. This is ridiculous and potentially
very harmful for performance.

> The core argument has been that it is a **basic 
> expectation** of the behavior of 2d array-like objects that 
> you will be able to get, e.g., the first element with x[0][0].
> (E.g., lists, tuples, arrays ... is there an exception??

For me this is wrong. list and tuples are not 2D. Numpy arrays happen to
offer this feature, but you should not use it do to multiple dimension
indexing.


> I teach with matrices and I thought you might too: if so, 
> you surely have run into this expectation (which is **natural**).

Well, I don't find it that natural. I would naturally expect A[0][0] to
be invalid. I have not heavily run into that expectation. People around
me are used to indexing with several indexes. This probably comes from
their fortran/Mathematica/Maple/Matlab background. I can see that someone
coming from C would expect this multiple consecutive indexing. This is
because C has no notion of multiple dimension objects. The C model is
limited and not as powerful as modern array programming languages, let us
just move along.

> In fact I truly doubt anyone has not been puzzled on first 
> encounter by this::

> >>> x
> matrix([[1, 2],
> [3, 4]])
> >>> x[0]
> matrix([[1, 2]])
> >>> x[0][0]
> matrix([[1, 2]])

Well, actually, I can say that this behavior is surprising. When I teach
numpy and somebody encounters this behavior (which doesn't happen often,
because people use multiple dimension indexing), I have to point out that
x[0] is a 2D object also.

I sympathize with your crusade to fix this inconvenience. This is why I
support the RowVector/ColumnVector proposal. However your proposal breaks
what I consider as normal and important for something I consider should
be avoided.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 11:15:14AM -0400, Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> > I don't see where you get your universality. 

> Lists, tuples, arrays ...
> Where is the exception?
> Only matrices are the only 2d container I can
> think of that are broken this way.

List and Tuples are not 2D containers.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> For me this is wrong. list and tuples are not 2D. Numpy 
> arrays happen to offer this feature, but you should not 
> use it do to multiple dimension indexing. 

But there is no proposal that people should index like this.
The underlying issue is iteration.  Currently::

>>> A
matrix([[1,  2],
[ 3,  4]])
>>> A = np.mat(x)
>>> for row in A:
...  for col in row:
...   print col
...
[[1  2]]
[[3 4]]

So are you saying that one should not be able to iterate 
through to the elements of a matrix?

So many natural expectations are broken by the current behavior!

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 02:01:45PM -0400, Alan G Isaac wrote:
> >>> A
> matrix([[1,  2],
> [ 3,  4]])
> >>> A = np.mat(x)
> >>> for row in A:
> ...  for col in row:
> ...   print col
> ...
> [[1  2]]
> [[3 4]]

> So are you saying that one should not be able to iterate 
> through to the elements of a matrix?

I kinda expect this was the real issue.

I think the only way to get consistent behavior for such code is either

* to use a syntax similar to dictionnaries:

for row in A.rows():
for col in row.cols()

  I actually think this is much better than the code you currently use,

* or implement row and column objects.

The problem in your code is that you do not distinguish iterating over
rows and columns, and in linear algebra these are different objects. The
two solutions I propose do this distinction. My favorite one is the first
one (the rows and cols methods).

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

>> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
>>> I don't see where you get your universality. 


> On Sat, Apr 26, 2008 at 11:15:14AM -0400, Alan G Isaac 
> wrote:
>> Lists, tuples, arrays ... 
>> Where is the exception? 
>> Only matrices are the only 2d container I can 
>> think of that are broken this way. 


On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> List and Tuples are not 2D containers. 


A list of lists is naturally conceived as 2d,
which is why you can initialize a 2d matrix
with a list of lists.

Try a Google search on "python two dimensional list"
to confirm that I am not promoting an anomalous view.

So I do not buy the way you are trying to parse
language here.  (Although I'm open to a fuller
argument.)

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 02:32:01PM -0400, Alan G Isaac wrote:
> A list of lists is naturally conceived as 2d,
> which is why you can initialize a 2d matrix
> with a list of lists.

> Try a Google search on "python two dimensional list"
> to confirm that I am not promoting an anomalous view.

> So I do not buy the way you are trying to parse
> language here.  (Although I'm open to a fuller
> argument.)

The object is not 2D. You can assemble several objects into something
that looks 2D, but it is not 2D.

For exemple:

[[1, 2, 3], [1, 2]]

This is not 2D in an nd array sens. It how exposes a double successiv
indexing, but doubly 1D, and no 2D.

For nD objects, I think people should rather use either nD indexing, or
explicite 1D indexing of an nD object. By this is mean "A[1, ...]" rather
than "A[1]". If the later breaks, I, for one, won't cry.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Travis E. Oliphant]

Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
>   
>> For me this is wrong. list and tuples are not 2D. Numpy 
>> arrays happen to offer this feature, but you should not 
>> use it do to multiple dimension indexing. 
>> 
>
> But there is no proposal that people should index like this.
> The underlying issue is iteration.  Currently::
>
> >>> A
> matrix([[1,  2],
> [ 3,  4]])
> >>> A = np.mat(x)
> >>> for row in A:
> ...  for col in row:
> ...   print col
> ...
> [[1  2]]
> [[3 4]]
>
> So are you saying that one should not be able to iterate 
> through to the elements of a matrix?
>   

Iteration can be handled separately with __iter__ method that returns 
the actual iterator object which may be different.   Or, as others have 
proposed .rows and .cols iterators.

I'm not personally persuaded by the iteration argument, because we can 
change iteration independently of mapping (__getitem__) access.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, "Travis E. Oliphant" apparently wrote:
> I'm not personally persuaded by the iteration argument, because we can 
> change iteration independently of mapping (__getitem__) access. 


Would that not impose another deviation from array behavior?
I just do not see the purpose.

I support .row and .cols iterators (returning submatrices),
and have included the idea for some time on the discussion
page http://www.scipy.org/MatrixIndexing>.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Gael Varoquaux wrote:
> * to use a syntax similar to dictionnaries:
> 
> for row in A.rows():
>   for col in row.cols()
> 
>   I actually think this is much better than the code you currently use,
> 
> * or implement row and column objects.
> 
> The problem in your code is that you do not distinguish iterating over
> rows and columns, and in linear algebra these are different objects. The
> two solutions I propose do this distinction. My favorite one is the first
> one (the rows and cols methods).

What would rows() and columns() return? I'd like them to return a vector 
object. If they return matrices, then you can't index them with a single 
value, if they return 1-d arrays, then you can't distinguish between 
rows and columns (which may be OK).

Travis E. Oliphant wrote:

> I'm not personally persuaded by the iteration argument, because we can 
> change iteration independently of mapping (__getitem__) access.

or just use:

for row in M.A:
   ...

How hard is that?


-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

oops, typo!

Christopher Barker wrote:
> Gael Varoquaux wrote:
>> 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]

I meant -- no one is suggesting:

element = M[i][j]

because, of course, M[i,j] is exactly what you should do do get an element.

Which, by the way, brings up another inconsistency in the current behavior:

 >>> M
matrix([[1, 2, 3],
 [4, 5, 6],
 [7, 8, 9]])
 >>> M[1,1]
5
 >>> M[1,:]
matrix([[4, 5, 6]])

so if you pull out a single element, you get a scalar(0-d), but if you 
pull out a row, you get a matrix(2-d). It makes me want vectors more...

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Mon, 28 Apr 2008, Christopher Barker apparently wrote:
> I'm going to try to put down what I think are the key, 
> very simple, questions:

For useful reference, these are now here:
http://www.scipy.org/MatrixIndexing#guidelines>

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 12:20 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:

> On Mon, 28 Apr 2008, Christopher Barker apparently wrote:
> > I'm going to try to put down what I think are the key,
> > very simple, questions:
>
> For useful reference, these are now here:
> http://www.scipy.org/MatrixIndexing#guidelines>
>
> Cheers,
> Alan
>
>
May I add that if I edit defmatrix.py to act like an array for scalar
indexing, then the following works.

In [1]: a = matrix(eye(2))

In [2]: array([a,a])
Out[2]:
array([[[ 1.,  0.],
[ 0.,  1.]],

   [[ 1.,  0.],
[ 0.,  1.]]])

This generates an error with the current version of matrix and, frankly, I
am not going to be bothered going all through the numpy c sources to special
case matrices to fix that. Someone else can do it if they wish. There are
recursive routines that expect the dimensions to decrease on each call.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Stéfan van der Walt]

Hi Charles

2008/4/29 Charles R Harris <[EMAIL PROTECTED]>:
> May I add that if I edit defmatrix.py to act like an array for scalar
> indexing, then the following works.
>
> In [1]: a = matrix(eye(2))
>
> In [2]: array([a,a])
> Out[2]:
> array([[[ 1.,  0.],
>  [ 0.,  1.]],
>
>[[ 1.,  0.],
> [ 0.,  1.]]])
>
> This generates an error with the current version of matrix and, frankly, I
> am not going to be bothered going all through the numpy c sources to special
> case matrices to fix that. Someone else can do it if they wish. There are
> recursive routines that expect the dimensions to decrease on each call.

I'd also like to see matrices become proper hierarchical containers --
the question is just how to do that.  Thus far, I'm most convinced by
the arguments for RowVectors/Columns, which leaves us with a sane
model for doing linear algebra, while providing the enhancements you
mentioned here and in comments to another ticket.

We were thinking of raising a warning on scalar indexing for 1.1, but
given the above, would that be sensical?

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Charles R Harris apparently wrote:
> There are recursive routines that expect the dimensions to 
> decrease on each call. 

I have added your example as anomaly #2 at the very top of 
the discussion page:
http://www.scipy.org/MatrixIndexing>

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Stéfan van der Walt apparently wrote:
> We were thinking of raising a warning on scalar indexing 
> for 1.1, but given the above, would that be sensical? 

There seem to be three basic proposals for scalar indexing:

- raise an error
- return a 1d array
- return a new type of 1d container (apparently to be called 
  a "vector" for some reason ...)

I do not think anyone is still arguing in favor of the 
keeping the current behavior (where scalar indexing returns 
a matrix)?

So the question seems to be: how best to warn users that the 
behavior of scalar indexing is very likely to change.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 7:24 AM, Stéfan van der Walt <[EMAIL PROTECTED]>
wrote:

> Hi Charles
>
> 2008/4/29 Charles R Harris <[EMAIL PROTECTED]>:
> > May I add that if I edit defmatrix.py to act like an array for scalar
> > indexing, then the following works.
> >
> > In [1]: a = matrix(eye(2))
> >
> > In [2]: array([a,a])
> > Out[2]:
> > array([[[ 1.,  0.],
> >  [ 0.,  1.]],
> >
> >[[ 1.,  0.],
> > [ 0.,  1.]]])
> >
> > This generates an error with the current version of matrix and, frankly,
> I
> > am not going to be bothered going all through the numpy c sources to
> special
> > case matrices to fix that. Someone else can do it if they wish. There
> are
> > recursive routines that expect the dimensions to decrease on each call.
>
> I'd also like to see matrices become proper hierarchical containers --
> the question is just how to do that.  Thus far, I'm most convinced by
> the arguments for RowVectors/Columns, which leaves us with a sane
> model for doing linear algebra, while providing the enhancements you
> mentioned here and in comments to another ticket.
>
> We were thinking of raising a warning on scalar indexing for 1.1, but
> given the above, would that be sensical?
>

Hi Stefan,

The numpy c routines call PySequence_GetItem(s,i) as well as ask for the
length (first index), so I think these should be left as they are for arrays
in order to guarantee that matrices are compatible with all the normal array
operations. This means either returning special row objects that index as
expected, or returning 1D arrays. I don't think the '*' operator has these
problems, but in any case that is a well documented feature of matrices.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> On Tue, Apr 29, 2008 at 7:24 AM, Stéfan van der Walt <[EMAIL PROTECTED] 
> > wrote:
>
> Hi Charles
>
> 2008/4/29 Charles R Harris <[EMAIL PROTECTED]
> >:
> > May I add that if I edit defmatrix.py to act like an array for
> scalar
> > indexing, then the following works.
> >
> > In [1]: a = matrix(eye(2))
> >
> > In [2]: array([a,a])
> > Out[2]:
> > array([[[ 1.,  0.],
> >  [ 0.,  1.]],
> >
> >[[ 1.,  0.],
> > [ 0.,  1.]]])
> >
> > This generates an error with the current version of matrix and,
> frankly, I
> > am not going to be bothered going all through the numpy c
> sources to special
> > case matrices to fix that. Someone else can do it if they wish.
> There are
> > recursive routines that expect the dimensions to decrease on
> each call.
>
> I'd also like to see matrices become proper hierarchical containers --
> the question is just how to do that.  Thus far, I'm most convinced by
> the arguments for RowVectors/Columns, which leaves us with a sane
> model for doing linear algebra, while providing the enhancements you
> mentioned here and in comments to another ticket.
>
> We were thinking of raising a warning on scalar indexing for 1.1, but
> given the above, would that be sensical?
>
>
> Hi Stefan,
>
> The numpy c routines call PySequence_GetItem(s,i) as well as ask for 
> the length (first index), so I think these should be left as they are 
> for arrays in order to guarantee that matrices are compatible with all 
> the normal array operations. This means either returning special row 
> objects that index as expected
> or returning 1D arrays. I don't think the '*' operator has these 
> problems, but in any case that is a well documented feature of matrices.

Thanks for looking in to this Chuck,

I'm quite persuaded now that a[i] should return a 1-d object for 
arrays.In addition to the places Chuck identified,  there are at 
least 2 other places where special code was written to work-around the 
expectation that item selection returns an object with reduced 
dimensionality (a special-cased .tolist for matrices and a special-cased 
getitem in the fancy indexing code).  

As the number of special-case work-arounds grows the more I'm convinced 
the conceptualization is wrong.   So, I now believe we should change the 
a[i] for matrices to return a 1-d array.  

The only down-side I see is that a[i] != a[i,:] for matrices.   
However,  matrix(a[i]) == a[i,:], and so I'm not sure there is really a 
problem, there.  I also don't think that whatever problem may actually 
be buried in the fact that type(a[i]) != type(a[i,:]) is worse than the 
problem that several pieces of NumPy code actually expect hierarchical 
container behavior of multi-dimensional sequences.  

I don't think making the small change to have a[i] return 1-d arrays 
precludes us from that 1-d array being a bit more formalized in 1.2 as a 
RowVector should we choose that direction.   It does, however, fix 
several real bugs right now.

So, I'm

+1 on making the following change:

def __getitem__(self, index):
+ if isscalar(index):
+ return self.__array__()[index]

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Alan G Isaac wrote:
> For useful reference, these are now here:
> 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

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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

>> http://www.scipy.org/MatrixIndexing#guidelines> 

On Tue, 29 Apr 2008, Christopher Barker apparently wrote: 
> Here are a few comments on that text 


In response, I have modified 
http://www.scipy.org/MatrixIndexing#guidelines>
to try to clarify what was meant and perhaps to address
your core concerns.

Alan

PS Perhaps I should note that I have come around to what 
I take to be Tim H's view that matrix indexing should should 
work just like ndarray indexing, except that when it 
produces a 2d result then a matrix is returned.  (This means 
giving up the current behavior of ``x[0,:]``.)  I also agree 
with those who want ``rows`` and ``cols`` attributes for 
iteration.  A small difference: I would have these yield 
matrices.  (I.e., no need for a new "vector" type.)



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Alan G Isaac wrote:
> Perhaps I should note that I have come around to what 
> I take to be Tim H's view that matrix indexing should should 
> work just like ndarray indexing, except that when it 
> produces a 2d result then a matrix is returned.  (This means 
> giving up the current behavior of ``x[0,:]``.)  I also agree 
> with those who want ``rows`` and ``cols`` attributes for 
> iteration.

+1 on all of that.

>  A small difference: I would have these yield 
> matrices.  (I.e., no need for a new "vector" type.)

So the only thing we "give up" (which we don't have now anyway) is 
something that acts like column and can be indexed like a 1-d object. I 
still think that would be nice, but maybe we're coming close to a 
consensus about the rest of it.

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Keith Goodman]

On Tue, Apr 29, 2008 at 10:11 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> indexing should should work just like ndarray indexing,
> except that when it produces a 2d result then a matrix
> is returned.  (This means giving up the current behavior
> of ``x[0,:]``.)

I often use x[i,:] and x[:,i] where x is a matrix and i is a scalar. I
hope this continues to return a matrix.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 10:49:50AM -0500, Travis E. Oliphant wrote:
> As the number of special-case work-arounds grows the more I'm convinced 
> the conceptualization is wrong.   So, I now believe we should change the 
> a[i] for matrices to return a 1-d array.  

> The only down-side I see is that a[i] != a[i,:] for matrices.   
> However,  matrix(a[i]) == a[i,:], and so I'm not sure there is really a 
> problem, there.

I think we have simply replaced one problem by another one. I think this
is a bad route to go. I think the only proposition that makes sens so far
is the RowVector/ColumnVector. Yes you return a 1D object, but one that
knows it is a linear algebra object, and not an array. I _really_ don't
like a[i] != a[i,:]. I also don't like loosing the information that you
are doing linear algebra.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
> I often use x[i,:] and x[:,i] where x is a matrix and i is 
> a scalar. I hope this continues to return a matrix. 

1. Could you give an example of the circumstances of this 
use?
2. Would any or all of the following be just as good 
a result?
a. 1d matrix
b. row and column vectors (1d but "oriented" for 
linear algebra purposes)
3. If 2a. and 2b. are no good for you,
a. would e.g. ``x[i:i+1,:]`` be too burdensome?
b. would ``rows`` and ``columns`` attributes that
yielded matrics be an offsetting convenience?

Thank you,
Alan Isaac

PS It is nice to have another matrix user in the conversation!

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> I really don't  like a[i] != a[i,:].

Tim H's proposal avoids that problem.
What do you think of it?


> I also don't like loosing the information that you are 
> doing linear algebra.

Hmmm.  Is it a given that asking for ``a[i]`` is "doing 
linear algebra"?  Is ``a[i:i+1,:]`` so bad if you want 
a matrix?  I think some more use cases, like Bill's, might 
prove clarifying.
http://www.scipy.org/ConjugateGradientExample>

Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Keith Goodman]

On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
>  > I often use x[i,:] and x[:,i] where x is a matrix and i is
>  > a scalar. I hope this continues to return a matrix.
>
>  1. Could you give an example of the circumstances of this
>  use?

In my use i is most commonly an array (i = M.where(y.A)[0] where y is
a nx1 matrix), sometimes a list, and in ipython when debugging or
first writing the code, a scalar. It would seem odd to me if x[i,:]
returned different types of objects based on the type of i:

array index
idx = M.where(y.A)[0] where y is a nx1 matrix
x[dx,:] -->  matrix

list index
idx = [0]
x[idx,:] --> matrix?

scalar index
idx = 0
x[idx,:] --> not matrix

>  2. Would any or all of the following be just as good
>  a result?
> a. 1d matrix
> b. row and column vectors (1d but "oriented" for
> linear algebra purposes)

For me, having arrays and matrices is confusing enough. Adding row and
column objects sounds even more confusing.

>  3. If 2a. and 2b. are no good for you,
> a. would e.g. ``x[i:i+1,:]`` be too burdensome?

Yes.

> b. would ``rows`` and ``columns`` attributes that
> yielded matrics be an offsetting convenience?

I like the idea, from earlier in the thread, of row and col being
iterators for those time when you want to work on one column or row at
a time.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 12:41 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:

> On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> > I really don't  like a[i] != a[i,:].
>
> Tim H's proposal avoids that problem.
> What do you think of it?
>
>
Of course, now we will have to remove all that special casing code...

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

I will answer this question too, because I feel like Keith.

On Tue, Apr 29, 2008 at 02:21:34PM -0400, Alan G Isaac wrote:
> On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
> > I often use x[i,:] and x[:,i] where x is a matrix and i is 
> > a scalar. I hope this continues to return a matrix. 

> 1. Could you give an example of the circumstances of this 
> use?

x[i, :]*A*x[:, i]

I find this cleaner, because more explicit, than x[i]*A*x[:, i]. I'd be
_very very_ upset if this broke. Breaking the explicit for the implicit
is a _bad_ idea, and if you go down this path you go down the path of
inconsistency.

> 2. Would any or all of the following be just as good 
> a result?
> a. 1d matrix

Yes.

> b. row and column vectors (1d but "oriented" for 
> linear algebra purposes)

Yes.

> 3. If 2a. and 2b. are no good for you,
> a. would e.g. ``x[i:i+1,:]`` be too burdensome?

No way. This is hard to read and the best way to make long calculations
impossible to follow and debug.

> b. would ``rows`` and ``columns`` attributes that
> yielded matrics be an offsetting convenience?

Hum, I don't love this because it introduces noise in the formulas, but
at least it is explicit and readable. 

I would really like us to go down the way of the row/vector columns. This
is consistent at least.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 02:41:45PM -0400, Alan G Isaac wrote:
> On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> > I really don't  like a[i] != a[i,:].

> Tim H's proposal avoids that problem.
> What do you think of it?

Sorry, I guess I am lost. Could you remind me which one it is? Given how
well you are summing up the discussion on
http://www.scipy.org/MatrixIndexing , I suspect it is already in the list
of proposal. 

> > I also don't like loosing the information that you are 
> > doing linear algebra.

> Hmmm.  Is it a given that asking for ``a[i]`` is "doing 
> linear algebra"?  Is ``a[i:i+1,:]`` so bad if you want 
> a matrix? 

Very, very bad. This is completly unreadable. Actually to the beginner,
this looks like a 2*N matrix, not a 1*N matrix.

To me you are really replacing a problem by another. We should fix the
problem, not replace it.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> x[i, :]*A*x[:, i] 
> I find this cleaner, because more explicit, than x[i]*A*x[:, i].

>> a. would e.g. ``x[i:i+1,:]``

> No way.


So *if* ``x[0]`` is going to be 1d to fix the many anomalies that 
have surfaced, then you would still want ``x[0]==x[0,:]``,
but to have those be 1d and have ``x[i, :]*A*x[:, i]`` work
would require (oriented) "vector" objects, so you would want
those.

Is that a fair summary of your view?

Cheers,
Alan Isaac


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Timothy Hochberg]

Let me throw out a couple of more thoughts:

First, there seems to be disagreement about what a row_vector and
column_vector are (and even if they are sensible concepts, but let's leave
that aside for moment). One school of thought is that they are
one-dimensional objects that have some orientation (hence row/column). They
correspond, more or less, to covariant and contravariant tensors, although I
can never recall which is which.  The second view, which I suspect is
influenced by MatLab and its ilk, is  that they are 2-dimensional 1xN and
Nx1 arrays. It's my view that the pseudo tensor approach is more powerful,
but it does require some metainformation be added to the array. This
metadata can either take the form of making the different objects different
classes, which leads to the matrix/row/column formulation, or adding some
sort of tag to the array object (proposal #5, which so far lacks any
detail).

Second, most of the stuff that we have been discussing so far is primarily
about notational convenience. However, there is matrix related stuff that is
at best poorly supported now, namely operations on stacks of arrays (or
vectors). As a concrete example, I at times need to work with stacks of
small matrices. If I do the operations one by one, the overhead is
prohibitive, however, most of that overhead can be avoided. For example, I
rewrote some of the linalg routines to work on stacks of matrices and
inverse is seven times faster for a 100x10x10 array (a stack of 100 10x10
matrices) when operating on a stack than when operating on the matrices one
at a time. This is a result of sharing the setup overhead, the C routines
that called are the same in either case.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 03:20:02PM -0400, Alan G Isaac wrote:
> On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> > x[i, :]*A*x[:, i] 
> > I find this cleaner, because more explicit, than x[i]*A*x[:, i].

> >> a. would e.g. ``x[i:i+1,:]``

> > No way.


> So *if* ``x[0]`` is going to be 1d to fix the many anomalies that 
> have surfaced, then you would still want ``x[0]==x[0,:]``,
> but to have those be 1d and have ``x[i, :]*A*x[:, i]`` work
> would require (oriented) "vector" objects, so you would want
> those.

> Is that a fair summary of your view?

That an extremely good summary of my views. Better than I could have
formulated it. Thank you.

Given this good short paragraph summing up the problem, as I see it, this
is why I think the only correct option is the oriented 1D objects. The
second best option is not to change anything in order not to break
backward compatibility.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> Could you remind me which one it is? 

Proposal #6 at 
http://www.scipy.org/MatrixIndexing#list-of-proposals>
is my effort to summarize what Tim was proposing.
It does not include the oriented 1d vectors that I think you 
need (if I have understood you).

Alan

PS For beginners, perhaps ``x[[i],:]`` would be better
than ``x[i:i+1,:]``.  It has other advantages too...



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 12:22:18PM -0700, Timothy Hochberg wrote:
>First, there seems to be disagreement about what a row_vector and
>column_vector are (and even if they are sensible concepts, but let's leave
>that aside for moment). One school of thought is that they are
>one-dimensional objects that have some orientation (hence row/column).
>They correspond, more or less, to covariant and contravariant tensors,
>although I can never recall which is which.  The second view, which I
>suspect is influenced by MatLab and its ilk, is  that they are
>2-dimensional 1xN and Nx1 arrays. It's my view that the pseudo tensor
>approach is more powerful, but it does require some metainformation be
>added to the array. This metadata can either take the form of making the
>different objects different classes, which leads to the matrix/row/column
>formulation, or adding some sort of tag to the array object (proposal #5,
>which so far lacks any detail).

Good summary. I support the 1D object with orientation, rather than the
2D object with special indexing. I would call the
row_vector/column_vectors bras and kets rather than tensors, but that
because I come from a quantum mechanics background.

>Second, most of the stuff that we have been discussing so far is primarily
>about notational convenience. However, there is matrix related stuff that
>is at best poorly supported now, namely operations on stacks of arrays (or
>vectors). As a concrete example, I at times need to work with stacks of
>small matrices. If I do the operations one by one, the overhead is
>prohibitive, however, most of that overhead can be avoided. For example, I
>rewrote some of the linalg routines to work on stacks of matrices and
>inverse is seven times faster for a 100x10x10 array (a stack of 100 10x10
>matrices) when operating on a stack than when operating on the matrices
>one at a time. This is a result of sharing the setup overhead, the C
>routines that called are the same in either case.

Good point. Do you have an idea to move away from this problem?

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 03:32:17PM -0400, Alan G Isaac wrote:
> On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> > Could you remind me which one it is? 

> Proposal #6 at 
> http://www.scipy.org/MatrixIndexing#list-of-proposals>
> is my effort to summarize what Tim was proposing.
> It does not include the oriented 1d vectors that I think you 
> need (if I have understood you).

I prefer proposal number 1.

> PS For beginners, perhaps ``x[[i],:]`` would be better
> than ``x[i:i+1,:]``.  It has other advantages too...


I think this will get beginners lost. From my experience, people take a
long time to understand indexing with an iterable. It is actually a
source of confusion, but I am not even remotely thinking of removing it,
because it is s nice, when you know how to use it.

Gaël 
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Keith Goodman]

On Tue, Apr 29, 2008 at 11:46 AM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>  > On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
>  >  > I often use x[i,:] and x[:,i] where x is a matrix and i is
>  >  > a scalar. I hope this continues to return a matrix.
>  >
>  >  1. Could you give an example of the circumstances of this
>  >  use?
>
>  In my use i is most commonly an array (i = M.where(y.A)[0] where y is
>  a nx1 matrix), sometimes a list, and in ipython when debugging or
>  first writing the code, a scalar. It would seem odd to me if x[i,:]
>  returned different types of objects based on the type of i:
>
>  array index
>  idx = M.where(y.A)[0] where y is a nx1 matrix
>  x[dx,:] -->  matrix
>
>  list index
>  idx = [0]
>  x[idx,:] --> matrix?
>
>  scalar index
>  idx = 0
>  x[idx,:] --> not matrix

Here's another use case:

for i in xrange(x.shape[1]):
xi = x[:,i]
idx = M.where(M.isfinite(xi).A)[0]
xi = xi[idx,:]
# more code

Also the functions I have written work on matrices. If x[i,:] did not
return a matrix, let's say it returned some other vector type object
that you index with a scalar, then my functions will have to test
whether the input is a full matrix or a vector since the indexing is
different.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Bruce Southey]

Hi,

On Tue, Apr 29, 2008 at 2:22 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
>
> Let me throw out a couple of more thoughts:
>
> First, there seems to be disagreement about what a row_vector and
> column_vector are (and even if they are sensible concepts, but let's leave
> that aside for moment). One school of thought is that they are
> one-dimensional objects that have some orientation (hence row/column). They
> correspond, more or less, to covariant and contravariant tensors, although I
> can never recall which is which.  The second view, which I suspect is
> influenced by MatLab and its ilk, is  that they are 2-dimensional 1xN and
> Nx1 arrays. It's my view that the pseudo tensor approach is more powerful,
> but it does require some metainformation be added to the array. This
> metadata can either take the form of making the different objects different
> classes, which leads to the matrix/row/column formulation, or adding some
> sort of tag to the array object (proposal #5, which so far lacks any
> detail).
>

Actually I think that this simply stems from the different variants of
linear (and more specifically matrix) algebra. My background is very
heavy in the statistical favor of this (what the heck are tensors...
http://mathworld.wolfram.com/Tensor.html). It is also clear (from that
definition) that others are from more physics and engineering
backgrounds. Hence all the back and forth because people have slightly
different usage, terminology and expectations.

The ability to treat vectors as matrices would be sufficient for my
needs because these are almost always used in the context of
vector-matrix multiplication. There is no additional benefit from
having row or column shapes or metadata because the row/column nature
is usually predetermined and would be represented by the shape of the
corresponding matrix. It really would be annoying to find that for an
n by 1 vector/matrix, the product of X.T*X is a scalar or an error
rather than an n by n matrix. Or requires additional code to get the
desired effect.


Regards
Bruce
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Keith Goodman]

On Tue, Apr 29, 2008 at 12:50 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:46 AM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>  > On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>  >  > On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
>  >  >  > I often use x[i,:] and x[:,i] where x is a matrix and i is
>  >  >  > a scalar. I hope this continues to return a matrix.
>  >  >
>  >  >  1. Could you give an example of the circumstances of this
>  >  >  use?
>  >
>  >  In my use i is most commonly an array (i = M.where(y.A)[0] where y is
>  >  a nx1 matrix), sometimes a list, and in ipython when debugging or
>  >  first writing the code, a scalar. It would seem odd to me if x[i,:]
>  >  returned different types of objects based on the type of i:
>  >
>  >  array index
>  >  idx = M.where(y.A)[0] where y is a nx1 matrix
>  >  x[dx,:] -->  matrix
>  >
>  >  list index
>  >  idx = [0]
>  >  x[idx,:] --> matrix?
>  >
>  >  scalar index
>  >  idx = 0
>  >  x[idx,:] --> not matrix
>
>  Here's another use case:
>
> for i in xrange(x.shape[1]):
> xi = x[:,i]
> idx = M.where(M.isfinite(xi).A)[0]
> xi = xi[idx,:]
> # more code
>
>  Also the functions I have written work on matrices. If x[i,:] did not
>  return a matrix, let's say it returned some other vector type object
>  that you index with a scalar, then my functions will have to test
>  whether the input is a full matrix or a vector since the indexing is
>  different.

And here's a use case that currently doesn't work but would be nice
(for me) if it did:

x[idx,i] = M.rand(2,1)

where x is a matrix, say 4x3, idx is an array with 2 elements, and i is a scalar
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Gael Varoquaux apparently wrote:
> I think the only correct option is the oriented 1D 
> objects. The second best option is not to change anything 
> in order not to break backward compatibility. 

Maybe the extant ``matrix`` class should be available for 
a while as ``oldmatrix``?

Alan


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
> here's a use case that currently doesn't work but would be nice 
> (for me) if it did:
> x[idx,i] = M.rand(2,1)


I think this is another example of the kind of thing we are trying to fix ...

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

On 29/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:

>  I'm quite persuaded now that a[i] should return a 1-d object for
>  arrays.In addition to the places Chuck identified,  there are at
>  least 2 other places where special code was written to work-around the
>  expectation that item selection returns an object with reduced
>  dimensionality (a special-cased .tolist for matrices and a special-cased
>  getitem in the fancy indexing code).
>
>  As the number of special-case work-arounds grows the more I'm convinced
>  the conceptualization is wrong.   So, I now believe we should change the
>  a[i] for matrices to return a 1-d array.
>
>  The only down-side I see is that a[i] != a[i,:] for matrices.
>  However,  matrix(a[i]) == a[i,:], and so I'm not sure there is really a
>  problem, there.  I also don't think that whatever problem may actually
>  be buried in the fact that type(a[i]) != type(a[i,:]) is worse than the
>  problem that several pieces of NumPy code actually expect hierarchical
>  container behavior of multi-dimensional sequences.

I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
object? Does this not require many special-case bits of code as well?
What about a[i,...]? That is what I would use to make a hierarchical
bit of code, and I would be startled to find myself in an infinite
loop waiting for the dimension to become one.

>  I don't think making the small change to have a[i] return 1-d arrays
>  precludes us from that 1-d array being a bit more formalized in 1.2 as a
>  RowVector should we choose that direction.   It does, however, fix
>  several real bugs right now.

+1

What's more, I think we need to have a matrix-cleanliness test suite
that verifies that all basic numpy tools behave identically on
matrices and preserve matrixiness. But that's a big job, and for 1.2.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote:
> I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
> object?

It breaks A*B[i, :] where A and B are matrices.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

On 29/04/2008, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote:
>  > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
>  > object?
>
> It breaks A*B[i, :] where A and B are matrices.

Really? How?

In [26]: A = np.matrix([[1,0],[0,1],[1,1]])

In [28]: A*np.ones(2)
Out[28]: matrix([[ 1.,  1.,  2.]])

In [29]: np.ones(3)*A
Out[29]: matrix([[ 2.,  2.]])


I guess you don't get dot products with *:

In [30]: np.ones(3).T*np.ones(3)
Out[30]: array([ 1.,  1.,  1.])

Since the whole point of matrices it to avoid having to type "dot" I
guess this should be convincing.


Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Timothy Hochberg]

On Tue, Apr 29, 2008 at 2:07 PM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:

> On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote:
> > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
> > object?
>
> It breaks A*B[i, :] where A and B are matrices.


Shouldn't that be B[i,:] * A? Or am I just confused?

In any event this wouldn't be a problem under row/column scheme or any of
the other results that end up tagging the results with some metainformation.
B[i] would be tagged as a row vector somehow and __mul__ would "do the right
thing" even though it was 1D.



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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

On 29/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:21 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>  > On Tue, 29 Apr 2008, Keith Goodman apparently wrote:
>  >  > I often use x[i,:] and x[:,i] where x is a matrix and i is
>  >  > a scalar. I hope this continues to return a matrix.
>  >
>  >  1. Could you give an example of the circumstances of this
>  >  use?
>
>
> In my use i is most commonly an array (i = M.where(y.A)[0] where y is
>  a nx1 matrix), sometimes a list, and in ipython when debugging or
>  first writing the code, a scalar. It would seem odd to me if x[i,:]
>  returned different types of objects based on the type of i:
>
>  array index
>  idx = M.where(y.A)[0] where y is a nx1 matrix
>  x[dx,:] -->  matrix
>
>  list index
>  idx = [0]
>  x[idx,:] --> matrix?
>
>  scalar index
>  idx = 0
>  x[idx,:] --> not matrix

It is actually pretty unreasonable to hope that

A[0]

and

A[[1,2,3]]
or
A[[True,False,True]]

should return objects of the same rank.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 3:07 PM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:

> On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote:
> > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
> > object?
>
> It breaks A*B[i, :] where A and B are matrices.


A*B[:,i], surely.

So it's a notational problem, what is the easiest way to get row/col vectors
out of a matrix. And it will be helpful if the notation is consistent and
easy to understand. In any case, dot doesn't care, so the fault above comes
from the matrix class itself.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Travis E. Oliphant]

Gael Varoquaux wrote:
> On Tue, Apr 29, 2008 at 10:49:50AM -0500, Travis E. Oliphant wrote:
>   
>> As the number of special-case work-arounds grows the more I'm convinced 
>> the conceptualization is wrong.   So, I now believe we should change the 
>> a[i] for matrices to return a 1-d array.  
>> 
>
>   
>> The only down-side I see is that a[i] != a[i,:] for matrices.   
>> However,  matrix(a[i]) == a[i,:], and so I'm not sure there is really a 
>> problem, there.
>> 
>
> I think we have simply replaced one problem by another one. I think this
> is a bad route to go. 
The problem is that I know exactly what the problem we are replacing, 
but I have no idea only vagueries about the problem we are getting.  So, 
in the short term, it seems like the right thing to do, because we 
aren't preventing a change to RowVector/ColumnVector in the future.

-Travis


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

> It breaks A*B[i, :] where A and B are matrices.
> 
> A*B[:,i], surely.

right. which is a really good argument for:

A * B.col[i]

(and .row, or course)

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 11:16:15PM +0200, Anne Archibald wrote:
> On 29/04/2008, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 29, 2008 at 11:03:58PM +0200, Anne Archibald wrote:
> >  > I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
> >  > object?

> > It breaks A*B[i, :] where A and B are matrices.

> Really? How?

> In [26]: A = np.matrix([[1,0],[0,1],[1,1]])

> In [28]: A*np.ones(2)
> Out[28]: matrix([[ 1.,  1.,  2.]])

> In [29]: np.ones(3)*A
> Out[29]: matrix([[ 2.,  2.]])

Yes, sorry, I am shameful. I should have thought a bit more before
posting.

There is no big problem with x[i,:] not being a 1-d object. The problem
is for x[:, i]. However I would find it nice that, for linear algebra, 
x[i, :] == x[:, i].T

This is the kind of behavior I expect, and we won't be getting it with 1D
arrays.

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Timothy Hochberg wrote:
> However, there is matrix related 
> stuff that is at best poorly supported now, namely operations on stacks 
> of arrays (or vectors).

Tim, this is important, but also appears to be an orthogonal issue to me 
-- whatever we do with matrices, rows, columns, whatever, we still need 
to solve this problem, and any of the schemes being proposed strikes me 
as amenable to having a "array or matrices", and the LA functions that 
act on them. What am I missing?

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Travis E. Oliphant]

> I am puzzled by this. What is the rationale for x[i,:] not being a 1-d
> object? Does this not require many special-case bits of code as well?
> What about a[i,...]? That is what I would use to make a hierarchical
> bit of code, and I would be startled to find myself in an infinite
> loop waiting for the dimension to become one.
>   

The rationale is so you can write

x[i,:] * A * x[:,i]

and have it work correctly without the RowVector / ColumnVector objects. 

Maybe it's just easier to create them and be done with it.  But, nobody 
has yet, so I'm not sure.

-Travis




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Keith Goodman wrote:
> It would seem odd to me if x[i,:]
>  returned different types of objects based on the type of i:

I think this is where matrices should act like arrays:

 >>> a
array([[0, 1, 2],
[3, 4, 5],
[6, 7, 8]])
 >>> a[:,[1]]
array([[1],
[4],
[7]])
 >>> a[:,1]
array([1, 4, 7])

in this case, it's not really different types, but totally different 
concepts -- indexing with a sequence is different than a scalar, just 
like indexing with a slice is different than a scalar.

There are many, many places in python code where we have to make 
distinctions between a single object and a sequence of objects that 
happens to be of length one.

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Bruce Southey wrote:
> The ability to treat vectors as matrices would be sufficient for my
> needs because these are almost always used in the context of
> vector-matrix multiplication. There is no additional benefit from
> having row or column shapes or metadata because the row/column nature
> is usually predetermined and would be represented by the shape of the
> corresponding matrix.

The benefit is that they can be indexed with a scalar and converted to a 
1-d array with r.A, and no reshaping. Also that indexing a matrix 
reduces its rank, which is expected in a lot of places.

> It really would be annoying to find that for an
> n by 1 vector/matrix, the product of X.T*X is a scalar or an error
> rather than an n by n matrix.

yes, it would, which is the whole point of the matrix object in the 
first place, and the point of the proposed row/column objects. They 
would provide 1-d object that behave as row an column vectors with * and **.

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Christopher Barker]

Gael Varoquaux wrote:
> However I would find it nice that, for linear algebra, 
> x[i, :] == x[:, i].T
> 
> This is the kind of behavior I expect, and we won't be getting it with 1D
> arrays.

But you WOULD get it with 1-d row/column objects.

I'm going to try to summarize what I think is clear from the discussion:

1) There are significant problems with the fact that the current matrix 
object does not reduce rank with indexing.

2) people want a "row" or "column" extracted from a matrix to behave 
like a linear algebra object, for example:  M[:,i] * M[i,:] is an matrix

As far as I can see, the ONLY way to satisfy both of these is with a 
row/column object of some sort.

You can get almost there by having M[i] return a 1-d array, while M[:,i] 
and M[i,:] continue to return Matrices, but this gives an asymmetry 
between extracting rows and columns, and, probably more important, breaks:

M[i] == M[i,:]

plus you don't get the benefit of being able to extract a row or column 
and index the result with a scalar.

-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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Timothy Hochberg]

On Tue, Apr 29, 2008 at 2:43 PM, Christopher Barker <[EMAIL PROTECTED]>
wrote:

> Timothy Hochberg wrote:
> > However, there is matrix related
> > stuff that is at best poorly supported now, namely operations on stacks
> > of arrays (or vectors).
>
> Tim, this is important, but also appears to be an orthogonal issue to me
> -- whatever we do with matrices, rows, columns, whatever, we still need
> to solve this problem, and any of the schemes being proposed strikes me
> as amenable to having a "array or matrices", and the LA functions that
> act on them. What am I missing?


Ah, that's a very good question. I'll do my best to answer it, it's been a
long time since I dug into this seriously, so I may make some missteps:
holler if you see something odd. Basically, I believe that you need two
things:

   1. The ability to make matrix/row/column objects of arbitrary
   dimensionality, where the extra dimensions contain the
   matrices/rows/columns. Current matrix objects are always 2D.
   2. A way to tell whether a given object represents a row, column or
   matrix. For instance, given a 2D object is it matrix or a stack of vectors.
   You might think that there's enough information implicit in the shape of the
   arrays in conjunction with the nature of the function called that this
   wouldn't be necessary, but it turns out not to be so. As I recall, I had to
   fudge things when I was trying to containerize linalg.solve, because there
   wasn't enough information available to figure out unambiguously the kinds of
   the arguments.

Any of the solutions that attach information to the array, such as your
matrix/row/col approach, or the quasi-tensor approach that I (and someone
else) have mentioned but never detailed, should work for this.

However, any of the solutions that involve trying to encode the information
into the array/matrix shape will probably not work. At least not well.
Fortunately, they seem to be losing traction.



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

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Tue, Apr 29, 2008 at 03:03:51PM -0700, Christopher Barker wrote:
> Gael Varoquaux wrote:
> > However I would find it nice that, for linear algebra, 
> > x[i, :] == x[:, i].T

> > This is the kind of behavior I expect, and we won't be getting it with 1D
> > arrays.

> But you WOULD get it with 1-d row/column objects.

Yes. I agree 100% with you that this is the best solution. I fully agree
with your complete message.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Keith Goodman]

On Tue, Apr 29, 2008 at 2:18 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
> On 29/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote:
>  > In my use i is most commonly an array (i = M.where(y.A)[0] where y is
>  >  a nx1 matrix), sometimes a list, and in ipython when debugging or
>  >  first writing the code, a scalar. It would seem odd to me if x[i,:]
>  >  returned different types of objects based on the type of i:
>  >
>  >  array index
>  >  idx = M.where(y.A)[0] where y is a nx1 matrix
>  >  x[dx,:] -->  matrix
>  >
>  >  list index
>  >  idx = [0]
>  >  x[idx,:] --> matrix?
>  >
>  >  scalar index
>  >  idx = 0
>  >  x[idx,:] --> not matrix
>
>  It is actually pretty unreasonable to hope that
>
>  A[0]
>
>  and
>
>  A[[1,2,3]]
>  or
>  A[[True,False,True]]
>
>  should return objects of the same rank.

Why it unreasonable to hope that

x[0,:]

and

x[0, [1,2,3]]

or

x[0, [True,False,True]]

where x is a matrix, continue to return matrices?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, "Travis E. Oliphant" apparently wrote:
> x[i,:] * A * x[:,i] 

This need is also fully met by Proposal 5.
It is just a matter of syntax and sticking
with matrices.
http://www.scipy.org/MatrixIndexing#proposal-5>

E.g., x.rows(i) * A * x.cols(i)

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Tue, 29 Apr 2008, Christopher Barker apparently wrote:
> a really good argument for:
> A * B.col[i] 

Also see the syntax discussed in Proposal 5.
(I am not expressing an opinion.)
http://www.scipy.org/MatrixIndexing#proposal-5>

One possibility is to let the rows and cols methods 
take an argument with a default of None. The default 
is to return an iterator over the rows/columns. An 
iterator over subsets of rows/columns could be 
specified with a sequence. A single row/column could 
be specified with a scalar argument.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

On 30/04/2008, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 2:18 PM, Anne Archibald
>  <[EMAIL PROTECTED]> wrote:
>  >  It is actually pretty unreasonable to hope that
>  >
>  >  A[0]
>  >
>  >  and
>  >
>  >  A[[1,2,3]]
>  >  or
>  >  A[[True,False,True]]
>  >
>  >  should return objects of the same rank.
>
> Why it unreasonable to hope that
>
>  x[0,:]
>
>  and
>
>  x[0, [1,2,3]]
>
>  or
>
>  x[0, [True,False,True]]
>
>  where x is a matrix, continue to return matrices?

Well, I will point out that your example is somewhat different from
mine; nobody is arguing that your three examples should return objects
of different ranks. There is some disagreement over whether

x[0,:]

should be a rank-1 or a rank-2 object, but x[0,[1,2,3]] and x[0,
[True, False, True]] should all have the same rank as x[0,:]. Nobody's
questioning that.

What I was pointing out is that x[0,0] should not have the same rank
as x[0,:] or x[0,[0]]. In this case it's obvious; x[0,0] should be a
scalar. But the same logic applies to
x[0,:]
versus
x[[0,1],:]
or even
x[[0],:].

For arrays, if x has rank 2, x[0,:] has rank 1. if L is a list of
indices, x[L,:] always has rank 2, no matter what is actually in L
(even if it's one element). It is perfectly reasonable that they
should yield objects of different ranks.

With matrices, we have the surprising result that x[0,:] is still a
two-dimensional object;  to get at its third element I have to specify
 x[0,:][0,2]. It seems to me that this is a peculiar hack designed to
ensure that the result still has "*" defined in a matrix way.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 1:22 PM, Timothy Hochberg <[EMAIL PROTECTED]>
wrote:

>
> Let me throw out a couple of more thoughts:
>
> First, there seems to be disagreement about what a row_vector and
> column_vector are (and even if they are sensible concepts, but let's leave
> that aside for moment). One school of thought is that they are
> one-dimensional objects that have some orientation (hence row/column). They
> correspond, more or less, to covariant and contravariant tensors, although I
> can never recall which is which.  The second view, which I suspect is
> influenced by MatLab and its ilk, is  that they are 2-dimensional 1xN and
> Nx1 arrays. It's my view that the pseudo tensor approach is more powerful,
> but it does require some metainformation be added to the array. This
> metadata can either take the form of making the different objects different
> classes, which leads to the matrix/row/column formulation, or adding some
> sort of tag to the array object (proposal #5, which so far lacks any
> detail).
>
> Second, most of the stuff that we have been discussing so far is primarily
> about notational convenience. However, there is matrix related stuff that is
> at best poorly supported now, namely operations on stacks of arrays (or
> vectors). As a concrete example, I at times need to work with stacks of
> small matrices. If I do the operations one by one, the overhead is
> prohibitive, however, most of that overhead can be avoided. For example, I
> rewrote some of the linalg routines to work on stacks of matrices and
> inverse is seven times faster for a 100x10x10 array (a stack of 100 10x10
> matrices) when operating on a stack than when operating on the matrices one
> at a time. This is a result of sharing the setup overhead, the C routines
> that called are the same in either case.
>

Some operations on stacks of small matrices are easy to get, for instance,
+,-,*,/, and matrix multiply. The last is the interesting one. If A and B
are stacks of matrices with the same number of dimensions with the matrices
stored in the last two indices, then

sum(A[...,:,:,newaxis]*B[...,newaxis,:,:], axis=-2)

is the matrix-wise multiplication of the two stacks. If B is replaced by a
stack of 1D vectors, x, it is even simpler:

sum(A[...,:,:]*x[...,newaxis,:], axis=-1)

This doesn't go through BLAS, but for large stacks of small matrices it
might be even faster than BLAS because BLAS is kinda slow for small
matrices.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Anne Archibald]

2008/4/30 Charles R Harris <[EMAIL PROTECTED]>:

> Some operations on stacks of small matrices are easy to get, for instance,
> +,-,*,/, and matrix multiply. The last is the interesting one. If A and B
> are stacks of matrices with the same number of dimensions with the matrices
> stored in the last two indices, then
>
> sum(A[...,:,:,newaxis]*B[...,newaxis,:,:], axis=-2)
>
> is the matrix-wise multiplication of the two stacks. If B is replaced by a
> stack of 1D vectors, x, it is even simpler:
>
> sum(A[...,:,:]*x[...,newaxis,:], axis=-1)
>
> This doesn't go through BLAS, but for large stacks of small matrices it
> might be even faster than BLAS because BLAS is kinda slow for small
> matrices.

Yes and no. For the first operation, you have to create a temporary
that is larger than either of the two input arrays. These invisible
(potentially) gigantic temporaries are the sort of thing that puzzle
users when as their problem size grows they suddenly find they hit a
massive slowdown because it starts swapping to disk, and then a
failure because the temporary can't be allocated. This is one reason
we have dot() and tensordot() even though they can be expressed like
this. (The other is of course that it lets us use optimized BLAS.)


This rather misses the point of Timothy Hochberg's suggestion (as I
understood it), though: yes, you can write the basic operations in
numpy, in a more or less efficient fashion. But it would be very
valuable for arrays to have some kind of metadata that let them keep
track of which dimensions represented simple array storage and which
represented components of a linear algebra object. Such metadata could
make it possible to use, say, dot() as if it were a binary ufunc
taking two matrices. That is, you could feed it two arrays of
matrices, which it would broadcast to the same shape if necessary, and
then it would compute the elementwise matrix product.

The question I have is, what is the right mathematical model for
describing these
arrays-some-of-whose-dimensions-represent-linear-algebra-objects?


One idea is for each dimension to be flagged as one of "replication",
"vector", or "covector". A column vector might then be a rank-1 vector
array, a row vector might be a rank-1 covector array, a linear
operator might be a rank-2 object with one covector and one vector
dimension, a bilinear form might be a rank-2 object with two covector
dimensions. Dimensions designed for holding repetitions would be
flagged as such, so that (for example) an image might be an array of
shape (N,M,3) of types ("replication","replication","vector"); then to
apply a color-conversion matrix one would simply use dot() (or "*" I
suppose). without too much concern for which index was which. The
problem is, while this formalism sounds good to me, with a background
in differential geometry, if you only ever work in spaces with a
canonical metric, the distinction between vector and covector may seem
peculiar and be unhelpful.

Implementing such a thing need not be too difficult: start with a new
subclass of ndarray which keeps a tuple of dimension types. Come up
with an adequate set of operations on them, and implement them in
terms of numpy's functions, taking advantage of the extra information
about each axis. A few operations that spring to mind:

* Addition: it doesn't make sense to add vectors and covectors; raise
an exception. Otherwise addition is always elementwise anyway. (How
hard should addition work to match up corresponding dimensions?)
* Multiplication: elementwise across "repetition" axes, it combines
vector axes with corresponding covector axes to get some kind of
generalized matrix product. (How is "corresponding" defined?)
* Division: mostly doesn't make sense unless you have an array of
scalars (I suppose it could compute matrix inverses?)
* Exponentiation: very limited (though I suppose matrix powers could
be implemented if the shapes are right)
* Change of basis: this one is tricky because not all dimensions need
come from the same vector space
* Broadcasting: the rules may become a bit byzantine...
* Dimension metadata fiddling

Is this a useful abstraction? It seems like one might run into trouble
when dealing with arrays whose dimensions represent vectors from
unrelated spaces.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Timothy Hochberg]

On Wed, Apr 30, 2008 at 8:16 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:

> 2008/4/30 Charles R Harris <[EMAIL PROTECTED]>:
>
> > Some operations on stacks of small matrices are easy to get, for
> instance,
> > +,-,*,/, and matrix multiply. The last is the interesting one. If A and B
> > are stacks of matrices with the same number of dimensions with the
> matrices
> > stored in the last two indices, then
> >
> > sum(A[...,:,:,newaxis]*B[...,newaxis,:,:], axis=-2)
> >
> > is the matrix-wise multiplication of the two stacks. If B is replaced by
> a
> > stack of 1D vectors, x, it is even simpler:
> >
> > sum(A[...,:,:]*x[...,newaxis,:], axis=-1)
> >
> > This doesn't go through BLAS, but for large stacks of small matrices it
> > might be even faster than BLAS because BLAS is kinda slow for small
> > matrices.
>
> Yes and no. For the first operation, you have to create a temporary
> that is larger than either of the two input arrays. These invisible
> (potentially) gigantic temporaries are the sort of thing that puzzle
> users when as their problem size grows they suddenly find they hit a
> massive slowdown because it starts swapping to disk, and then a
> failure because the temporary can't be allocated. This is one reason
> we have dot() and tensordot() even though they can be expressed like
> this. (The other is of course that it lets us use optimized BLAS.)
>
>
> This rather misses the point of Timothy Hochberg's suggestion (as I
> understood it), though: yes, you can write the basic operations in
> numpy, in a more or less efficient fashion. But it would be very
> valuable for arrays to have some kind of metadata that let them keep
> track of which dimensions represented simple array storage and which
> represented components of a linear algebra object. Such metadata could
> make it possible to use, say, dot() as if it were a binary ufunc
> taking two matrices. That is, you could feed it two arrays of
> matrices, which it would broadcast to the same shape if necessary, and
> then it would compute the elementwise matrix product.
>
> The question I have is, what is the right mathematical model for
> describing these
> arrays-some-of-whose-dimensions-represent-linear-algebra-objects?
>
>
> One idea is for each dimension to be flagged as one of "replication",
> "vector", or "covector". A column vector might then be a rank-1 vector
> array, a row vector might be a rank-1 covector array, a linear
> operator might be a rank-2 object with one covector and one vector
> dimension, a bilinear form might be a rank-2 object with two covector
> dimensions. Dimensions designed for holding repetitions would be
> flagged as such, so that (for example) an image might be an array of
> shape (N,M,3) of types ("replication","replication","vector"); then to
> apply a color-conversion matrix one would simply use dot() (or "*" I
> suppose). without too much concern for which index was which. The
> problem is, while this formalism sounds good to me, with a background
> in differential geometry, if you only ever work in spaces with a
> canonical metric, the distinction between vector and covector may seem
> peculiar and be unhelpful.
>
> Implementing such a thing need not be too difficult: start with a new
> subclass of ndarray which keeps a tuple of dimension types. Come up
> with an adequate set of operations on them, and implement them in
> terms of numpy's functions, taking advantage of the extra information
> about each axis. A few operations that spring to mind:
>
> * Addition: it doesn't make sense to add vectors and covectors; raise
> an exception. Otherwise addition is always elementwise anyway. (How
> hard should addition work to match up corresponding dimensions?)
> * Multiplication: elementwise across "repetition" axes, it combines
> vector axes with corresponding covector axes to get some kind of
> generalized matrix product. (How is "corresponding" defined?)
> * Division: mostly doesn't make sense unless you have an array of
> scalars (I suppose it could compute matrix inverses?)
> * Exponentiation: very limited (though I suppose matrix powers could
> be implemented if the shapes are right)
> * Change of basis: this one is tricky because not all dimensions need
> come from the same vector space
> * Broadcasting: the rules may become a bit byzantine...
> * Dimension metadata fiddling
>
> Is this a useful abstraction? It seems like one might run into trouble
> when dealing with arrays whose dimensions represent vectors from
> unrelated spaces.


Thanks Anne. That is exactly what I had in mind. Alas, every time I sit down
to try to prototype some code, it collapses under its own weight. I'm
becoming warmer to an extended version of the row/col/matrix idea just
because its simpler to understand. It would be just as you describe above
but would support only four cases:

   1. scalar: all axes are 'replication' axes
   2. vector: last axes is a 'vector' all other replication.
   3. covector: last axes is a 'covector' all o

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Wed, Apr 30, 2008 at 9:16 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:

> 2008/4/30 Charles R Harris <[EMAIL PROTECTED]>:
>
> > Some operations on stacks of small matrices are easy to get, for
> instance,
> > +,-,*,/, and matrix multiply. The last is the interesting one. If A and
> B
> > are stacks of matrices with the same number of dimensions with the
> matrices
> > stored in the last two indices, then
> >
> > sum(A[...,:,:,newaxis]*B[...,newaxis,:,:], axis=-2)
> >
> > is the matrix-wise multiplication of the two stacks. If B is replaced by
> a
> > stack of 1D vectors, x, it is even simpler:
> >
> > sum(A[...,:,:]*x[...,newaxis,:], axis=-1)
> >
> > This doesn't go through BLAS, but for large stacks of small matrices it
> > might be even faster than BLAS because BLAS is kinda slow for small
> > matrices.
>
> Yes and no. For the first operation, you have to create a temporary
> that is larger than either of the two input arrays. These invisible
> (potentially) gigantic temporaries are the sort of thing that puzzle
> users when as their problem size grows they suddenly find they hit a
> massive slowdown because it starts swapping to disk, and then a
> failure because the temporary can't be allocated. This is one reason
> we have dot() and tensordot() even though they can be expressed like
> this. (The other is of course that it lets us use optimized BLAS.)
>

But it is interesting that you can multiply stacks of matrices that way, is
it not? I haven't seen it mentioned elsewhere.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion