Re: [Numpy-discussion] matrices in 1.1
On Sat, Mar 22, 2008 at 4:40 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Hi Alan On Fri, Mar 21, 2008 at 7:11 PM, Alan G Isaac [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stéfan van der Walt apparently wrote: The last I remember, we considered adding RowVector, ColumnVector and letting slices out of a matrix either be one of those or a matrix itself. There was a subsequent discussion. If there was, I still don't remember the result being the one you suggested (could be my bad memory, but maybe you can post a link as a reminder). I simply don't see a Matrix as a container of ndarrays That is hardly an argument. Not an argument, just my opinion or perspective. In the matrix world, everything has a minimum dimension of 2, so I don't see how you can contain ndarrays in a matrix. Remember, any indexing that when applied to an 2d array would produce a 2d array will when applied to a matrix still produce a matrix. Sure. This is really just principle of least surprise. Or not, depending on where you come from. I'd expect indexing operations that produce 1D-arrays on ndarrays to produce 2D-arrays on matrices. PS Are you a *user* of matrices? No, I'm not (I love the consistency of the ndarray approach, and broadcasting always does the Right Thing (TM)). Although I do sometimes use matrices when I'm lazy to apply dot, i.e. A,B,C,D = [np.asmatrix(a) for a in [arr1,arr2,arr3,arr4]] result = (A*B*C*D).A Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, 22 Mar 2008, Stéfan van der Walt apparently wrote: maybe you can post a link as a reminder URL:http://projects.scipy.org/pipermail/numpy-discussion/2008-February/031548.html In the matrix world, everything has a minimum dimension of 2, so I don't see how you can contain ndarrays in a matrix. Are you trying to suggest that in most matrix programming languages if you extract a row you will then need to use two indices to extract an element of that row? This does not match my experience. I would ask you to justify that by listing the languages you have in mind. Additionally, you surely see how you can do this. But as someone who does not use matrices much, you have an *abstract* objection to allowing this desirable functionality. (As far as I can tell, this objection is grounded in how you have chosen to think about matrices as mathematical objects, but nothing in the math implies your objection.) Provocatively, I might boil your position down to simply asserting that the only thing I should be able to get out of a matrix is a submatrix, and then being willing to break some nice ndarray behavior that would be expected by most new matrix users for no reason other than to enforce your arbitrary assertion. Since you offer NO MORE than an unfounded assertion, there is really no reason to stop me from e.g. getting the i,j-th element of a matrix as M[i][j]. Instead you want to just break this (which is the current status). Remember, you will still be able to extract the first row of a matrix ``M`` as a **submatrix** using ``M[0,:]``. No functionality would be lost under my proposed change. In short, the behavior change I have requested will - mean that habits formed using ndarrays transfer naturally to the use of matrices - increase functionality without removing any functionality Breaking the nice behavior of ndarrays should have a really strong justification. No real justification has been given for breaking e.g. the ability to use M[i] to get the i-th row as an array or M[i][j] to get the i,j-th element. Oddly, the weak justifications that have been offered have been offered by people who make little or no use of matrices. This behavior has been broken arbitrarily. The breakage removes useful functionality, adds no new functionality, needlessly decreases similarities between matrices and ndarrays, and thereby surprises new users (e.g., my students) for no good reason. As a final observation, I will note that status quo bias of course works against making this change, but making this desirable change by 1.1 will be easier than making it later. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
Hi Alan On Sat, Mar 22, 2008 at 5:49 PM, Alan G Isaac [EMAIL PROTECTED] wrote: Are you trying to suggest that in most matrix programming languages if you extract a row you will then need to use two indices to extract an element of that row? This does not match my experience. I would ask you to justify that by listing the languages you have in mind. No, I agree with you that that is unintuitive -- but it can be solved by introducing Row and ColumnVectors, which are still 2-dimensional. One important result you don't want is: In [9]: x = np.array([[1,2,3],[4,5,6],[7,8,9]]) In [10]: x[:,0] Out[10]: array([1, 4, 7]) But instead the current behaviour: In [11]: x = np.matrix([[1,2,3],[4,5,6]]) In [12]: x[:,0] Out[12]: matrix([[1], [4]]) Remember, you will still be able to extract the first row of a matrix ``M`` as a **submatrix** using ``M[0,:]``. No functionality would be lost under my proposed change. Do I understand correctly that you want M[0,:] and M[0] to behave differently? Would you like M[0] to return the first element of the matrix as in Octave? Is there a reason why the Column/Row-vector solution wouldn't work for you? In short, the behavior change I have requested will - mean that habits formed using ndarrays transfer naturally to the use of matrices But other habits, such as x[0,:] and x[0] meaning the same thing, won't transfer so well. So you're just swapping one set of inconveniences for another. I'm not trying to sabotage your proposal, I just want to understand it better. If I'm the only one who is not completely satisfied, then please, submit a patch and have it applied. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, Mar 21, 2008 at 06:12:09PM -0500, Travis E. Oliphant wrote: I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. I don't. I think some people are going to scratch their head wondering what the code does pretty badly. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, Mar 22, 2008 at 4:43 PM, Gael Varoquaux [EMAIL PROTECTED] wrote: On Fri, Mar 21, 2008 at 06:12:09PM -0500, Travis E. Oliphant wrote: I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. I don't. I think some people are going to scratch their head wondering what the code does pretty badly. It's just the evaluation of a linear function. What's strange about that? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, Mar 22, 2008 at 7:02 PM, Alan G Isaac [EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 5:49 PM, Alan G Isaac [EMAIL PROTECTED] wrote: Are you trying to suggest that in most matrix programming languages if you extract a row you will then need to use two indices to extract an element of that row? This does not match my experience. I would ask you to justify that by listing the languages you have in mind. On Sat, 22 Mar 2008, Stéfan van der Walt apparently wrote: No, I agree with you that that is unintuitive -- but it can be solved by introducing Row and ColumnVectors, which are still 2-dimensional. To me, this seems to be adding a needless level of complexity. I am not necessarily opposing it; I just do not see a commensurate payoff. In contrast, I see great payoff to keeping as much ndarray behavior as possible. One important result you don't want is: In [9]: x = np.array([[1,2,3],[4,5,6],[7,8,9]]) In [10]: x[:,0] Out[10]: array([1, 4, 7]) Agreed. I would hope it has been clear from earlier discussion that the proposal retains that any use of multiple indexes will produce a 2d submatrix. That offers a simple way to say how matrix indexing will differ from ndarray indexing. Do I understand correctly that you want M[0,:] and M[0] to behave differently? Yes. Again, I think that I have been consistent on this point. Any use of multiple indexes such as M[0,:] will produce a 2d submatrix. Any use of scalar indexes such as M[0] behave as with an ndarray. Would you like M[0] to return the first element of the matrix as in Octave? No! Deviations from ndarray behavior should be minimized. They should be: 1. Multiplication is redefined to matrix multiplication. 2. Powers are redefined accordingly. 3. The ``A`` and ``I`` attributes. 4. Any use of multiple indexes will produce a 2d submatrix. I think that is it. If I'm the only one who is not completely satisfied, then please, submit a patch and have it applied. Always a reasonable request, but with respect to NumPy, I'm a user not a developer. That said, it looks to be simple: perhaps no more than adding to __getitem__ after the existing lines:: if not isinstance(out, N.ndarray): return out two new lines:: if isscalar(index): return out (Not that I like multiple points of return from a function.) All this for want of an operator ;) Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Use ``asmatrix``. (Does not copy.) After that the only needed unification I have encountered is that iteration over a matrix should return arrays (not matrices). I believe this is under consideration for 1.1. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Stéfan van der Walt apparently wrote: The last I remember, we considered adding RowVector, ColumnVector and letting slices out of a matrix either be one of those or a matrix itself. There was a subsequent discussion. I simply don't see a Matrix as a container of ndarrays That is hardly an argument. Remember, any indexing that when applied to an 2d array would produce a 2d array will when applied to a matrix still produce a matrix. This is really just principle of least surprise. Or, if you want a complementary way of looking at it, it is keeping as much of the natural behavior of the ndarray as possible while adding convenient submatrices, matrix multiplication, and inverse. Cheers, Alan Isaac PS Are you a *user* of matrices? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. BTW, A matrix is just a rank 2 tensor, so matrix (tensor) algebra can be applied to an arbitrary rank tensor, for example APL's . operator. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם Alan G Isaac נשלח: ו 21-מרץ-08 16:23 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] matrices in 1.1 On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Use ``asmatrix``. (Does not copy.) After that the only needed unification I have encountered is that iteration over a matrix should return arrays (not matrices). I believe this is under consideration for 1.1. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
Charles R Harris wrote: On Fri, Mar 21, 2008 at 1:57 PM, Alan G Isaac [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. I suspect what you are really wanting is a way for NumPy to define new operators ... I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
One problem with the matrix class is that it follows matlab way too much. For example: a = arange(9).reshape(3,3) A = asmatrix(a) v = arange(3) dot(a, v) array([ 5, 14, 23]) A*v Traceback (most recent call last): File pyshell#15, line 1, in module A*v File C:\Python25\lib\site-packages\numpy\core\defmatrix.py, line 157, in __mul__ return N.dot(self, asmatrix(other)) ValueError: objects are not aligned I do a lot of colour image processing. Most of the time I treat an image as a MxNx3 array, but some time I have to do matrix/ vector operations like colour-space conversion. In these cases the dot function becomes very handy (better then Matlab matrix multiplication), since I can write: new_image = dot(old_image, A) where A is either a 3x3 matrix or a length 3 vector. The result is that my code is cluttered with a lot of dots, and the matrix class can not help much. It is possible that my case is special and does not justify a special attention, but if many of us do colour/spectral imaging, or other type of high-rank tensors algebra, there could be a case to give numpy an edge. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם Travis E. Oliphant נשלח: ש 22-מרץ-08 01:12 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] matrices in 1.1 Charles R Harris wrote: On Fri, Mar 21, 2008 at 1:57 PM, Alan G Isaac [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. I suspect what you are really wanting is a way for NumPy to define new operators ... I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, 22 Mar 2008, Nadav Horesh apparently wrote: A*v ... ValueError: objects are not aligned This is just how I want matrices to act! If A is m׳n, then v should be n׳1 for A*v to be defined. Anything else is trouble waiting to happen. But it seems that Charles's proposal would make life more convenient for you... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
