On Tue, 27 Mar 2007, Zachary Pincus apparently wrote:
Now, Bill offers up a different suggestion: indexing
M yields neither a matrix nor an array, but a class that
operates more or less like an array, except insofar as it
interacts with other matrix objects, or other objects of
similar
What I envisioned was that M[i,:] would return a row_vector and M
[:,j] would return a column_vector, because this would be symmetric
behavior. M[i], by convention, would behave the same as M[i,:].
But then I personally don't distinguish between python indexing and
numpy indexing. In both
On 3/29/07, Bill Spotz [EMAIL PROTECTED] wrote:
What I envisioned was that M[i,:] would return a row_vector and M
[:,j] would return a column_vector, because this would be symmetric
behavior. M[i], by convention, would behave the same as M[i,:].
But then I personally don't distinguish between
On Mar 29, 2007, at 6:48 PM, Alan G Isaac wrote:
On Thu, 29 Mar 2007, Bill Spotz apparently wrote:
What I envisioned was that M[i,:] would return
a row_vector and M[:,j] would return a column_vector,
because this would be symmetric behavior. M[i], by
convention, would behave the same as
matrix.py
The discussion about matrix indexing has been interminible and for
the most part pretty pointless IMO. However, it does point out one
thing: the interaction between the matrix and array classes is still
pretty klunky despite a fair amount of effort trying to make them
interoperate.
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column vector with
a row vector:
(c)(r)
Traceback (most recent call last):
...
TypeError: Cannot matrix multiply columns with anything
That should be allowed. (N,1)*(1,M) is just
On 3/29/07, Bill Baxter [EMAIL PROTECTED] wrote:
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column vector with
a row vector:
(c)(r)
Traceback (most recent call last):
...
TypeError: Cannot matrix multiply columns with
On 3/29/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
On 3/29/07, Bill Baxter [EMAIL PROTECTED] wrote:
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column vector
with
a row vector:
(c)(r)
Traceback (most recent call
On 3/29/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
On 3/29/07, Bill Baxter [EMAIL PROTECTED] wrote:
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column vector
with
a row vector:
(c)(r)
Traceback (most recent call
Looks promising!
On 3/29/07, Bill Baxter [EMAIL PROTECTED] wrote: On 3/30/07,
Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column
vector with
a row vector:
(c)(r)
Traceback (most recent call last):
...
TypeError: Cannot
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
On 3/29/07, Bill Baxter [EMAIL PROTECTED] wrote:
On 3/30/07, Timothy Hochberg [EMAIL PROTECTED] wrote:
Note, however that you can't (for instance) multiply column vector with
a row vector:
(c)(r)
Traceback (most recent call
Alan G Isaac wrote:
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
Alan G Isaac wrote:
I take it from context that you consider it desirable
to end up with a list of matrices?
Robert wrote:
Honestly, I don't care. You asked about iteration, and
On Tue, 27 Mar 2007, Zachary Pincus wrote:
M[i], which equals M[i,:]
Of course this equality must break.
That was stated at the outset.
As I said before, this may be impossible
or undesirable. But, as I said before,
it seems prima facie natural for
M[i] to be ordinary Python indexing
while
On Wed, Mar 28, 2007 at 07:05:00PM -0500, Alan Isaac wrote:
On Wed, 28 Mar 2007, Stefan van der Walt wrote:
Matrices strike me as a bit of an anomaly. I would expect
an N-dimensional container to contain (N-1)-dimensional
objects.
Yes indeed.
Doesn't seem to be the way the matrix
On Tue, 27 Mar 2007, Bill Baxter apparently wrote:
xformedPt = someComplicatedNonLinearThing(pt)
I do stuff like the above quite frequently in my code,
although with arrays rather than matrices.
Exactly: that was one other thing I found artificial.
Surely the points will then be wanted as
Exactly: that was one other thing I found artificial.
Surely the points will then be wanted as arrays.
So my view is that we still do not have a use case
for wanting matrices yielded when iterating across
rows of a matrix.
It's pretty clear from my perspective: 1-D slices of matrices *must*
Zachary Pincus wrote:
rest of linear algebra -- e.g. that m[0] yields a matrix if m is a
matrix-- it almost certainly would violate the principle of least
surprise for iteration over m (intuitively understood to be choosing m
[0] then m[1] and so forth) to yield anything other than a
Alan G Isaac wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
This is again simple assertion.
**Why** would one expect this?
Some people clearly do not.
One person commented
Alan Isaac wrote:
On Mon, 26 Mar 2007, Travis Oliphant wrote:
It actually has been offered. You just don't accept it.
Matrices are containers of matrices.
If M is an (mxn) matrix then M[0] is a (1xn) matrix.
Viewing this 1xn matrix as a 1-d array loses it's row-vectorness.
Hello all,
I suspect my previous email did not contain the full chain of my
reasoning, because I thought that some parts were basically obvious.
My point was merely that given some pretty basic fundamental tenants
of numpy, Alan's suggestions quickly lead to *serious issues* far
worse
Hi Zach,
The use case I requested was for iteration over a
matrix where it is desirable that matrices are yielded.
That is not what you offered.
The context for this request is my own experience:
whenever I have needed to iterate over matrices,
I have always wanted the arrays. So I am simply
Alan G Isaac wrote:
Hi Zach,
The use case I requested was for iteration over a
matrix where it is desirable that matrices are yielded.
That is not what you offered.
The context for this request is my own experience:
whenever I have needed to iterate over matrices,
I have always wanted
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
I take it from context that you consider it desirable
to end up with a list of matrices?
I guess I would find it more natural to work with the
arrays, but perhaps that starts just being taste.
Thank you,
Alan
Alan G Isaac wrote:
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
I take it from context that you consider it desirable
to end up with a list of matrices?
Honestly, I don't care. You asked about iteration, and I gave you an example
where it was
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
Alan G Isaac wrote:
I take it from context that you consider it desirable
to end up with a list of matrices?
Robert wrote:
Honestly, I don't care. You asked about iteration, and
I gave you an
Bill Baxter wrote:
On 3/26/07, Colin J. Williams [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
This may sound silly, but I really think seeing all those brackets is
what makes it feel wrong. Matlab's output doesn't put it in your
face that your 4 is really a matrix([[4]]), even though that's
Alan G Isaac wrote:
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
finds itself in basic conflict with the idea that
I ought to be able to iterate over the objects in an
iterable container. I mean really, does this not feel
wrong? ::
for item in x: print item.__repr__()
Alan G Isaac wrote:
Alan G Isaac wrote:
So this ::
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
Of course I realize that I can just ::
x.A[1]
array([1, 0])
On Sun, 25 Mar 2007, Colin J. Williams apparently wrote:
An array and
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
Perhaps things would be clearer if we thought of the
constituent groups of data in a matrix as being themselves
matrices.
This thinking of is what you have suggested before.
You need to explain why it is not begging the question.
Alan G Isaac schrieb:
X[1]
array([3,4])
X[1,:]
matrix([[3, 4]])
But again the point is:
indexing for submatrices should produce matrices.
Normal Python indexing should access the constituent arrays.
On Mon, 26 Mar 2007, Sven Schreiber apparently wrote:
I think
Alan G Isaac schrieb:
What feels wrong: iterating over a container does not give
access to the contained objects. This is not Pythonic.
If you iterate over the rows of the matrix, it feels natural to me to
get the row vectors -- and as you know a 1d-array does not contain the
information
Alan G Isaac schrieb:
What feels wrong: iterating over a container does not give
access to the contained objects. This is not Pythonic.
On Mon, 26 Mar 2007, Sven Schreiber apparently wrote:
If you iterate over the rows of the matrix, it feels
natural to me to get the row vectors
On Mon, 26 Mar 2007, Sebastian Haase apparently wrote:
A matrix is an object that you expect a certain
(mathematical !) behavior from. If some object behaves
intuitively right -- that's ultimately pythonic!
The problem is, as I am not the only one to point out,
this particular behavior is
Alan G Isaac wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
Perhaps things would be clearer if we thought of the
constituent groups of data in a matrix as being themselves
matrices.
This thinking of is what you have suggested before.
You need to explain why it is not
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
This is again simple assertion.
**Why** would one expect this?
Some people clearly do not.
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
**Why** would one expect this?
Some people clearly
Since matrices are an iterable Python object,
we *expect* to iterate over the contained objects.
(Arrays.) I am not sure why this is not evident to all,
but it is surely the sticking point in this discussion.
A matrix is not a container of matrices.
That it acts like one is surprsing.
Alan G Isaac wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
**Why**
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
On Mon, 26 Mar 2007, Travis Oliphant wrote:
It actually has been offered. You just don't accept it.
Matrices are containers of matrices.
If M is an (mxn) matrix then M[0] is a (1xn) matrix.
Viewing this 1xn matrix as a 1-d array loses it's row-vectorness.
This seems perfectly
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
May I see a use case where the desired
return when iterating through a matrix
is rows as matrices? That has never
been what I wanted.
On Tue, 27 Mar 2007, Bill Baxter wrote:
AllMyPoints = mat(rand(100,2)) # 100 two-d points
for pt in
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
May I see a use case where the desired
return when iterating through a matrix
is rows as matrices? That has never
been what I wanted.
On Tue, 27 Mar 2007, Bill Baxter wrote:
AllMyPoints
One thing keeps bugging me when I use numpy.matrix.
All this is fine::
x=N.mat('1 1;1 0')
x
matrix([[1, 1],
[1, 0]])
x[1,:]
matrix([[1, 0]])
But it seems to me that I should be able
to extract a matrix row as an array.
So this ::
x[1]
matrix([[1,
Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
So this ::
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
Of course I realize that I can just ::
x.A[1]
array([1, 0])
but since the above keeps feeling wrong I felt I should
Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
I think the point here is that if you are using matrices,
then all you should
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
I think the point here is
Alan G Isaac wrote:
One thing keeps bugging me when I use numpy.matrix.
All this is fine::
x=N.mat('1 1;1 0')
x
matrix([[1, 1],
[1, 0]])
x[1,:]
matrix([[1, 0]])
But it seems to me that I should be able
to extract a matrix row as an array.
This
Alan G Isaac wrote:
Em Dom, 2007-03-25 Ã s 13:07 -0400, Alan G Isaac escreveu:
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
I think the point here is that if you are using matrices,
Bill Baxter wrote:
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
I think the
On 3/26/07, Colin J. Williams [EMAIL PROTECTED] wrote:
Bill Baxter wrote:
This may sound silly, but I really think seeing all those brackets is
what makes it feel wrong. Matlab's output doesn't put it in your
face that your 4 is really a matrix([[4]]), even though that's what it
is to
Alan G Isaac wrote:
So this ::
x[1]
matrix([[1, 0]])
feels wrong. (Similarly when iterating across rows.)
Of course I realize that I can just ::
x.A[1]
array([1, 0])
On Sun, 25 Mar 2007, Colin J. Williams apparently wrote:
An array and a matrix are different
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
finds itself in basic conflict with the idea that I ought
to be able to iterate over the objects in an iterable
container.
I mean really, does this not feel wrong? ::
for item in x: print item.__repr__()
...
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
finds itself in basic conflict with the idea that I ought
to be able to iterate over the objects in an iterable
container.
I mean really, does this not feel wrong? ::
for item in
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
finds itself in basic conflict with the idea that
I ought to be able to iterate over the objects in an
iterable container. I mean really, does this not feel
wrong? ::
for item in x: print item.__repr__()
...
matrix([[1,
Oooops, they should match of course. ::
X[1]
array([3,4])
X[1,:]
matrix([[3, 4]])
But again the point is:
indexing for submatrices should produce matrices.
Normal Python indexing should access the constituent arrays.
Cheers,
Alan Isaac
55 matches
Mail list logo
