>
> I'm positive I've seen col * row come up in other contexts too, though
> I can't think of any other particulars right now.
>
Add to that quasi-Newton updates for quadratic models in optimization,
like the BFGS.
Paulo
___
Numpy-discussion mailing
On 3/29/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
"""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
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)
> > >
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):
> > ...
>
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)
> > Tracebac
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)
> > Tracebac
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 col
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)*(
"""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 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 sam
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 M[i,:].
Can you please be explicit about the
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 betwee
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 bo
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
> simil
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 m
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.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Num
On Wed, Mar 28, 2007 at 05:25:57PM -0500, Alan Isaac wrote:
> given the surprising passion of the attacks at the
> suggestion that perhaps iteration over a matrix might more
> consistently yield arrays, I presumed there must be *many*
> instances in which it was obviously desirable that such
>
It's because the property that A[i] == A[i,...] is much more
important to most numpy users than the results of a particular (mis)
use of the matrix class.
This has been explained in many different contexts over many
different email messages by many different people. You're not looking
at th
On Wed, 28 Mar 2007, Robert Kern wrote:
> People have been giving you reasons, over and over again.
> You are simply refusing to listen to them.
Exploring whether the reasoning is adequate is not the same
as refusing to listen. I do not presume my view is correct.
> You have a use case for a
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 M
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 ab
>> 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 y
On Tue, 27 Mar 2007, Fernando Perez wrote:
> it's probably worth mentioning, as a data point, that the
> python language has a well established precedent for
> 'iteration over a FOO where a FOO is yielded':
> In [1]: s='abc'
Yes.
And I recall being bitten by this long ago.
Now it feels natura
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 imp
On 3/27/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:
So we are left with the current behavior:
(a) M[i,:] is a matrix.
(b) M[i] is a matrix.
(c) Iteration over M yields matrices.
I find it useful if M[i] indexes the matrix interpreted as a column-vector
(vec(M), or M(:) in
Matlab notation),
On 3/27/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Hi Zach,
>
> The use case I requested was for iteration over a
> matrix where it is desirable that matrices are yielded.
I'm personally not really partial to any side of this discussion,
given how I don't use matrices at all (I'm content with a
> 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.
No, I offered a thorough discussion of why the design of numpy, as I
imperfectly understand it, make the trade-offs to achieve your
desired goal unpalat
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 I
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
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
int
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 than
It seems to me that using shapes, (m,1) versus (1,n), to determine
whether a vector is column- or row-oriented is a hack (or at least
feels like one). If we know we have a vector, then we want to use a
single index to obtain a scalar, and that extra "0," or ",0"
shouldn't be necessary.
It
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-vectornes
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 perso
I would like to hear your opinion on developing an explicit sparse/dense 2D
matrix class with indexing similar to Matlab, and without significant
differences between sparse and dense matrices from the user's
perspective...
I know that it's not one of Numpy/Scipy's goals to clone Matlab, but I
th
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 m
> 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 *
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
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 w
> 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
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.
If you use a row vector convention it make plenty of sense.
AllMyPoints = mat(rand(100,2)) # 100 two-d p
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 l
On Mon, 26 Mar 2007, Charles R Harris wrote:
> What happens is a convention
Certainly true.
> It isn't going to change now, it would break too much
> code.
That is a different kind of argument.
It might be true.
May I see a use case where the desired
return when iterating through a matrix
is
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 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.
>
>
>
>
>>On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Th
> 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
>> 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?
>>
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
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 that this unexpected beh
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 wh
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
On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > 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 th
> 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
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:
>> >>> 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 apparen
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 questio
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"
Alan G Isaac schrieb:
> 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.
>
I think this
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: prin
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
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
_
>> 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? ::
> 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:
>> 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 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
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 appare
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 a
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
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 thi
> 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 y
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
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]
matr
73 matches
Mail list logo
