Menu
▾
▴
numpy-discussion
|
From: Ed S. <sch...@ft...> - 2006-07-07 13:50:50
|
Bill Baxter wrote: > I think the thread to this point can be pretty much summarized by: > > while True: > Bill: "2D transpose is common so it should have a nice syntax" > Tim, Robert, Sasha, and Ed: "No it's not." > > Very well. I think it may be a self fulfilling prophecy, though. > I.e. if matrix operations are cumbersome to use, then -- surprise > surprise -- the large user base for matrix-like operations never > materializes. Potential converts just give numpy the pass, and go to > Octave or Scilab, or stick with Matlab, R or S instead. > > Why all the fuss about the .T? Because any changes to functions (like > making ones() return a matrix) can easily be worked around on the user > side, as has been pointed out. But as far as I know -- do correct me > if I'm wrong -- there's no good way for a user to add an attribute to > an existing class. After switching from matrices back to arrays, .T > was the only thing I really missed from numpy.matrix. > > I would be all for a matrix class that was on equal footing with array > and as easy to use as matrices in Matlab. But my experience using > numpy.matrix was far from that, and, given the lack of enthusiasm for > matrices around here, that seems unlikely to change. However, I'm > anxious to see what Ed has up his sleeves in the other thread. Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;) I'd like to know why you, Sven, and anyone else on the list have gone back to using arrays after trying matrices. What was inconvenient about them? I'd like a nice juicy list. The whole purpose of the matrix class is to simplify 2d linear algebra. Where is it failing? I also went back to arrays after trying out matrices for some 2d linear algebra tasks, since I found that using matrices increased my code's complexity. I can describe the problems I had with them later, but first I'd like to hear of others' experiences. I'd like to help to make matrices more usable. Tell me what you want, and I'll work on some patches. -- Ed |
|
From: Bill B. <wb...@gm...> - 2006-07-07 15:08:03
|
On 7/7/06, Ed Schofield <sch...@ft...> wrote:
>
> Bill Baxter wrote:
> > I would be all for a matrix class that was on equal footing with array
> > and as easy to use as matrices in Matlab. But my experience using
> > numpy.matrix was far from that, and, given the lack of enthusiasm for
> > matrices around here, that seems unlikely to change. However, I'm
> > anxious to see what Ed has up his sleeves in the other thread.
>
> Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;)
> I'd like to know why you, Sven, and anyone else on the list have gone
> back to using arrays after trying matrices. What was inconvenient about
> them? I'd like a nice juicy list. The whole purpose of the matrix
> class is to simplify 2d linear algebra. Where is it failing?
Okay, here are a few that come to mind.
1) Functions that take a matrix but return an array. Maybe these are all
fixed now. But they better be fixed not just in numpy but in scipy too. To
me this implies there needs to be some standard idiom for how to write a
generic array-protocol-using function so that you don't have to think about
it.
2) At the time I was using matrix, scalar * matrix was broken. Fixed now,
but that kind of thing just shouldn't happen. There should be a tests for
basic operations like that if there aren't already.
3) mat() doesn't make sense as a shortcut for matrix construction. It only
saves 3 letters over typing matrix(), and asmatrix is generally more
useful. So mat() should be a synonym for asmatrix()
4) eye,empty,rand,ones,zeros,arange and anything else that builds an array
from scratch or from a python list should have a matrix equivalent.
5) I've got squeezes like crazy all over my matrix-using code. Maybe this
was a bug in 0.9.5 or so that's been fixed? I do seem to recall some
problem with indexing or c_ or something that was causing matrices to grow
extra levels of length 1 axes. Again, like the scalar*matrix bug, things
like that shouldn't happen.
6) No good way to do elementwise operations? Sometimes you just want to do
an elementwise mult or divide or exponentiation. I guess you're supposed to
do Z = asmatrix(X.A * Y.A). Yah, right.
7) Finally, once all that is fixed, I find the slavish adherance to ndim=2
to be too restrictive.
a) Sometimes it's useful to have a stack of matrices. Pretty often, in
fact, for me. I guess I could use a python list of matrices or an object
array of matrix or something, but I also think there are times when it's
useful to treat different pairs of axes as the 'matrix' part. So I'd like
matrices to be able to have ndim>2.
b) On the other end, I think ndim<2 is useful sometimes too. Take a
function like mean(), for example. With no arguments the return value is a
1x1 matrix (as opposed to a scalar). That just looks silly. And it doesn't
work everywhere a scalar would, e.g. with a python built-in like round().
Or take indexing. It seems odd to me that where() reurns a tuple of
shape==(1,N) objects instead of just (N,) . Maybe I can get over that
though, as long as it works for indexing (which it seems it does). But I
think the scalar return case is a real issue. Here's another: sum(). For
an array you can do sum(sum(a)) and get a scalar if a is 2-d, but for matrix
sum(sum(m)) is the same as sum(m). And along these lines, m[newaxis] just
silently doesn't do anything. That doesn't seem right.
That's all I can think of for now.
Beyond that, looming in the back of my mind there's the question of what
happens when we decide we want to have sparse matrices? Or masked sparse
matrices, for that matter. These specialty array objects all seem to me
like they should be some sort of mix-ins. The features they provide are
(conceptually, anyway) independent. Concrete sibling classes doesn't really
seem like the right inheritance relationship.
> I'd like to help to make matrices more usable. Tell me what you want,
> and I'll work on some patches.
Thanks for giving it a shot. I'm currently trying to compile numpy from svn
on Win32 for the first time myself. If it goes well I can probably help run
tests or maybe even on some coding. But I still have yet to get past ATLAS.
--Bill
|
|
From: Tim H. <tim...@co...> - 2006-07-07 21:21:20
|
So, I put together of a prototype dot function dot( |
|
From: Tim H. <tim...@co...> - 2006-07-07 21:22:01
|
Tim Hochberg wrote: > > > So, I put together of a prototype dot function > > dot( > Ooops! This wasn't supposed to go out yet, sorry. More later. -tim |
|
From: JJ <jos...@ya...> - 2006-07-09 00:10:10
|
Hello. My 2 cents may be late on this, but I do have some thoughts as a matlab user switching over to numpy/scipy. I will just list my points, and I have a general question at the end. 1) I vote for a simple way to allow matrices to be the default (vs arrays), with all matrix operations/functions/range selections returning matrices. 2) Allowing more than 2D matrices would be nice, but I dont need them often. 3) In some operations, especially range selection operations, a N,1 matrix is turned into a 1,N matrix. This is confusing relative to matlab and problematic, in my view. 3) From my experience so far, range selection is by far the most problematic part of using numpy. In matlab, range selection is very easy and intuitive. For example, if X is a 10 x 5 matrix, a = X[X[:,1]<3,1:3] works just fine. In numpy it is much more confusing and the code to do this is relatively lengthy. It would be nice if range selection for a matrix could be done using any combination of boolean and/or integer matrices (not lists or arrays, necessarily). For example, boolean selection for rows and integer selection for columns. 4) It would be very nice if range selection could be done with real numbers, such as 1.0, 2.0, etc. Matlab can do this and it makes the code much simpler. 5) If X is a 1,n matrix, then X.T should return a n,1 matrix, I think. I guess thats my main points. And now I have a question. What do people think about the role of numpy/scipy vs. R (other than one is python and one is not)? What are the benefits of numpy/scipy over R? In the future, do numpy users want stat libraries like R has? Or put another way, when numpy/scipy is mature, when would you use numpy and when would you use R? Thanks. JJ (John) |
|
From: Ed S. <sch...@ft...> - 2006-07-09 06:35:11
|
On 08/07/2006, at 10:22 PM, JJ wrote: > 3) In some operations, especially range selection operations, a N, > 1 matrix is > turned into a 1,N matrix. This is confusing relative to matlab and > problematic, > in my view. This sounds like a bug. Can you give any examples of this happening with the latest release or SVN version? > <snip> > > 5) If X is a 1,n matrix, then X.T should return a n,1 matrix, I > think. This should be the case. Could you post a code snippet that violates it? Thanks for your feedback, JJ! -- Ed |
|
From: JJ <jos...@ya...> - 2006-07-09 08:10:41
|
Ed Schofield <schofield <at> ftw.at> writes: > > > On 08/07/2006, at 10:22 PM, JJ wrote: > > > 3) In some operations, especially range selection operations, a N, > > 1 matrix is > > turned into a 1,N matrix. This is confusing relative to matlab and > > problematic, > > in my view. > > This sounds like a bug. Can you give any examples of this happening > with the latest release or SVN version? > > > <snip> > > > > 5) If X is a 1,n matrix, then X.T should return a n,1 matrix, I > > think. > > This should be the case. Could you post a code snippet that violates > it? > > Thanks for your feedback, JJ! > ----------------------------------------- Hello Ed: Here are a couple of examples off the top of my head: a = mat(arange(10)) a.shape = (5,2) b = a.copy() c = hstack((a,b)) # should return a matrix type(c) <type 'numpy.ndarray'> a[where(a[:,0]<6)[0],0] #should return a column matrix([[0, 2, 4]]) My version is about a month old, so maybe these are fixed. Since we are on the topic, I dont understand why where() returns a tupple. To me, it just means adding an extra '[0]' in many places in my code. I would vote for where() retuning a matrix (if matrix is the default in the session). My comment on transpose of a 1,n matrix producing a n,1 matrix was in response to a vote question on the list. Also, I would vote for X.A*Y.A to return a matrix, if matrix is the default for a session. Lastly, this might not be the right place for this comment, but it would be nice if pylab allowed numpy matrices. Then code like: plot(d.A.ravel().tolist()) could be changed to plot(d) Hope this is of some help. JJ |
|
From: Sven S. <sve...@gm...> - 2006-07-09 14:56:10
|
JJ schrieb: > ----------------------------------------- > Hello Ed: > Here are a couple of examples off the top of my head: > > a = mat(arange(10)) > a.shape = (5,2) > b = a.copy() > c = hstack((a,b)) # should return a matrix > type(c) > <type 'numpy.ndarray'> This hstack bug has been fixed recently. > > a[where(a[:,0]<6)[0],0] #should return a column > matrix([[0, 2, 4]]) Don't know anything about this stuff. > > My version is about a month old, so maybe these are fixed. Since we are on the > topic, I dont understand why where() returns a tupple. To me, it just means > adding an extra '[0]' in many places in my code. I would vote for where() > retuning a matrix (if matrix is the default in the session). My comment on > transpose of a 1,n matrix producing a n,1 matrix was in response to a vote > question on the list. That discussion was about pure arrays, not the matrix subclass. > matrix is the default for a session. Lastly, this might not be the right place > for this comment, but it would be nice if pylab allowed numpy matrices. I agree, that would be nice! Maybe we can team up and invade the matplotlib mailing list some time ;-) -sven |
|
From: Keith G. <kwg...@gm...> - 2006-07-07 15:45:24
|
On 7/7/06, Ed Schofield <sch...@ft...> wrote:
> I'd like to help to make matrices more usable. Tell me what you want,
> and I'll work on some patches.
I can't pass up an offer like that.
DIAG
diag(M) returns an array. It would be nice if diag(M) returned
asmatrix(diag(M)).T. It would also be nice if you can construct a
diagonal matrix directly from what is returned from diag(M). But right
now you can't:
>> x
matrix([[0, 1, 2],
[3, 4, 5],
[6, 7, 8]])
>> diag(x)
array([0, 4, 8])
>> d = asmatrix(diag(x)).T
>> d
matrix([[0],
[4],
[8]])
>> diag(d)
array([0]) <-- this should be a 3x3 matrix
MATRIX CONSTRUCTION
Making it easier to construct matrices would be a big help. Could the
following function be made to return matrices?
ones, zeros, rand, randn, eye, linspace, empty
I guess the big decision is how to tell numpy to use matrices. How about
from numpy.matrix import ones, zeros ?
I would prefer something even more global. Something that acts like
the global variable 'usematrix = True'. Once that is declared, the
default changes from array to matrix.
INDEXING
>> x
matrix([[0, 1, 2],
[3, 4, 5],
[6, 7, 8]])
>> y
matrix([[0],
[1],
[2]])
>> x[y>1,:]
matrix([[6]])
This is a big one for me. If x[y>1,:] returned
>> x[2,:]
matrix([[6, 7, 8]])
then there would no longer be a need for array :)
|
|
From: Travis O. <oli...@ie...> - 2006-07-07 18:13:17
|
Bill Baxter wrote: > On 7/7/06, *Ed Schofield* <sch...@ft... <mailto:sch...@ft...>> > wrote: > > Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;) > I'd like to know why you, Sven, and anyone else on the list have gone > back to using arrays after trying matrices. What was inconvenient > about > them? I'd like a nice juicy list. The whole purpose of the matrix > class is to simplify 2d linear algebra. Where is it failing? > > > Okay, here are a few that come to mind. > 1) Functions that take a matrix but return an array. Maybe these are > all fixed now. But they better be fixed not just in numpy but in > scipy too. To me this implies there needs to be some standard idiom > for how to write a generic array-protocol-using function so that you > don't have to think about it. A lot of these are fixed. The mechanism for handling this is in-place: either using asanyarray in the function or (more generally) using a decorator that wraps the arguments with asarray and returns the output with __array_wrap__. But, we need people to help with fleshing it out. > > 2) At the time I was using matrix, scalar * matrix was broken. Fixed > now, but that kind of thing just shouldn't happen. There should be a > tests for basic operations like that if there aren't already. We need people to write and implement the tests. It's one way everybody can contribute. I do use matrices occasionally (not never as has been implied). But, I do more coding than linear algebra (particularly with images), therefore my need for matrix math is reduced. Nonetheless, I've been very willing to make well-defined changes that are needed. Most problems cannot be found out without people who use and test the code. > > 3) mat() doesn't make sense as a shortcut for matrix construction. It > only saves 3 letters over typing matrix(), and asmatrix is generally > more useful. So mat() should be a synonym for asmatrix() I'd be willing to make that change, but it will break some people's SciPy code. > > 4) eye,empty,rand,ones,zeros,arange and anything else that builds an > array from scratch or from a python list should have a matrix equivalent Would from numpy.defmatrix import ones, zeros, ... work? > > 5) I've got squeezes like crazy all over my matrix-using code. Maybe > this was a bug in 0.9.5 or so that's been fixed? I do seem to recall > some problem with indexing or c_ or something that was causing > matrices to grow extra levels of length 1 axes. Again, like the > scalar*matrix bug, things like that shouldn't happen. Sure, but it's going to happen in a beta release... That's why we need testers. As I recall, most bugs with matrices have been fixed fairly quickly as soon as they are reported. > > 6) No good way to do elementwise operations? Sometimes you just want > to do an elementwise mult or divide or exponentiation. I guess you're > supposed to do Z = asmatrix(X.A * Y.A). Yah, right. This is a problem with a dearth of infix operators. In fact, if we had a good way to write matrix multiplication as an infix operator, perhaps there wouldn't be any need for matrices. I'm really not sure how to fix the problem (the .M attribute of arrays was an attempt to make it easier): (X.A * Y.A).M But, there is always multiply(X,Y) > > 7) Finally, once all that is fixed, I find the slavish adherance to > ndim=2 to be too restrictive. > a) Sometimes it's useful to have a stack of matrices. Pretty > often, in fact, for me. I guess I could use a python list of matrices > or an object array of matrix or something, but I also think there are > times when it's useful to treat different pairs of axes as the > 'matrix' part. So I'd like matrices to be able to have ndim>2. I suppose this restriction could be lifted. > b) On the other end, I think ndim<2 is useful sometimes too. Take > a function like mean(), for example. With no arguments the return > value is a 1x1 matrix (as opposed to a scalar). Have you checked lately. It's a scalar now... This has been fixed. > Or take indexing. It seems odd to me that where() reurns a tuple of > shape==(1,N) objects instead of just (N,) . The way to fix some of these is to return arrays for indexing instead of allowing matrices. But, matrices that are less than 2-d just don't make sense. > Maybe I can get over that though, as long as it works for indexing > (which it seems it does). But I think the scalar return case is a > real issue. Here's another: sum(). For an array you can do > sum(sum(a)) and get a scalar if a is 2-d, but for matrix sum(sum(m)) > is the same as sum(m). And along these lines, m[newaxis] just > silently doesn't do anything. That doesn't seem right. These are just semantic questions. It's no surprise that sum(sum(m)) returns the same as sum(m) for a matrix because summing over the same axis won't change the result. You have to sum over both axes in a matrix. Thanks for the feedback. -Travis |
|
From: Bill B. <wb...@gm...> - 2006-07-08 14:25:02
|
On 7/8/06, Travis Oliphant <oli...@ie...> wrote: > > > Okay, here are a few that come to mind. > > 1) Functions that take a matrix but return an array. Maybe these are > > all fixed now. But they better be fixed not just in numpy but in > > scipy too. To me this implies there needs to be some standard idiom > > for how to write a generic array-protocol-using function so that you > > don't have to think about it. > > A lot of these are fixed. The mechanism for handling this is in-place: > either using asanyarray in the function or (more generally) using a > decorator that wraps the arguments with asarray and returns the output > with __array_wrap__. That sounds good. Is there a description of what that does and how to use it anywhere you could point me to? > 5) I've got squeezes like crazy all over my matrix-using code. Maybe > > this was a bug in 0.9.5 or so that's been fixed? I do seem to recall > > some problem with indexing or c_ or something that was causing > > matrices to grow extra levels of length 1 axes. Again, like the > > scalar*matrix bug, things like that shouldn't happen. > Sure, but it's going to happen in a beta release... That's why we need > testers. As I recall, most bugs with matrices have been fixed fairly > quickly as soon as they are reported. What do you mean by "beta release"? Are the odds considered betas and evens releases? Or do you mean just everything prior to 1.0 is actually beta? I haven't seen anything actually labeled as "beta" yet. And yes, you've done a fantastic job fixing bugs quickly, and getting releases out in a pretty timely manner too. Many thanks for that. > > > 6) No good way to do elementwise operations? Sometimes you just want > > to do an elementwise mult or divide or exponentiation. I guess you're > > supposed to do Z = asmatrix(X.A * Y.A). Yah, right. > This is a problem with a dearth of infix operators. In fact, if we had > a good way to write matrix multiplication as an infix operator, perhaps > there wouldn't be any need for matrices. Actually I was more after what you mentioned later -- the multiply(a,b) function. I see they're all there -- multiply, divide, power. That's all I wanted, because I know the Python operator overload situation doesn't really allow more than that. > ...So I'd like matrices to be able to have ndim>2. > I suppose this restriction could be lifted. I think that would be an improvement for people who want to use matrix as their only ndarray data type. > b) On the other end, I think ndim<2 is useful sometimes too. Take > > a function like mean(), for example. With no arguments the return > > value is a 1x1 matrix (as opposed to a scalar). > Have you checked lately. It's a scalar now... This has been fixed. Nope, haven't checked more recently than the latest release. I'm in the process of trying to build numpy, though. > Or take indexing. It seems odd to me that where() reurns a tuple of > > shape==(1,N) objects instead of just (N,) . The way to fix some of these is to return arrays for indexing instead of > allowing matrices. But, matrices that are less than 2-d just don't > make sense. I guess not. Looking at what matlab does more closely I see that it does report size (1,1) for all scalars, and either 1,N or N,1 for all vectors. It just hides it better. Namely when printing you don't get as many superfluous brackets (in fact matlab doesn't print any brackets). > Maybe I can get over that though, as long as it works for indexing > > (which it seems it does). But I think the scalar return case is a > > real issue. Here's another: sum(). For an array you can do > > sum(sum(a)) and get a scalar if a is 2-d, but for matrix sum(sum(m)) > > is the same as sum(m). And along these lines, m[newaxis] just > > silently doesn't do anything. That doesn't seem right. > > These are just semantic questions. It's no surprise that sum(sum(m)) > returns the same as sum(m) for a matrix because summing over the same > axis won't change the result. You have to sum over both axes in a > matrix. Right, it is perfectly logical given how sum is implemented. I guess I'm just used to Matlab's way which acts more like sum on arrays. But maybe numpy's way is ok too. --bill |
|
From: Sven S. <sve...@gm...> - 2006-07-07 20:44:59
|
Ed Schofield schrieb: > > Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;) > I'd like to know why you, Sven, and anyone else on the list have gone > back to using arrays after trying matrices. What was inconvenient about > them? I'd like a nice juicy list. The whole purpose of the matrix > class is to simplify 2d linear algebra. Where is it failing? No, no, I must have given the wrong impression, I'm still in the matrix camp. My main complaint would have been absence of equivalents for ones, zeros, etc., but it seems Travis has introduced numpy.matlib exactly for that, which is great. Before that, I sometimes felt like a second-class citizen because many people on the list argued that users should invent their own workarounds (which btw I have done in the meantime, but that's not the purpose of a ready-to-use matrix package, is it?). > > I'd like to help to make matrices more usable. Tell me what you want, > and I'll work on some patches. > Well if numpy.matlib does what I think it does there are no pressing issues for me right now. Element-wise multiplication isn't that important for me. Of course I'll let you know as soon as something occurs to me ;-) Thanks for offering, Sven |
|
From: Keith G. <kwg...@gm...> - 2006-07-07 23:01:48
|
On 7/7/06, Travis Oliphant <oli...@ie...> wrote: > Bill Baxter wrote: > > 4) eye,empty,rand,ones,zeros,arange and anything else that builds an > > array from scratch or from a python list should have a matrix equivalent > Would > > from numpy.defmatrix import ones, zeros, ... > > work? Can defmatrix be shortened to matrix? So from numpy.matrix import ones, zeros, ... |
|
From: Bill B. <wb...@gm...> - 2006-07-08 12:21:10
|
My preferred way to import numpy currently is:
import numpy as num
It would be nice if I could do:
import numpy.matrix as num
And basically have access to all the same stuff that's in the base numpy but
have everything set up in a matrix-like way, so num.ones returns a matrix
instead of an array, etc. (I don't care so much about the particular
name... matlib, matrixlib, matrixdefault, or whatever -- I just care about
the functionality)
The way I understand this matlib module is that I would do something along
the lines of one of these:
1) import numpy as num
from numpy.matlib import ones, zeros,...
or
2) import numpy as num
import numpy.matlib as M
Either way, the matrix functions aren't in the same namespace as general
numpy functions, which makes it feel like something of a bolt-on rather than
a second equally valid way to use numpy. So what I'd like is
3) import numpy.matlib as num
I think the way to get 3) may be to just do a "from numpy import *" at the
beginning of the numpy.matlib module, before redefining particular functions
with matrix versions. Maybe that's a bad idea, though?
Or maybe this is the way Travis and others planned for it to work from the
beginning? At any rate, versions 1) and 2) should also be supported for the
times you don't want to use matlib as the default, but still want access to
it.
--bill
|
|
From: JJ <jos...@ya...> - 2006-07-09 08:24:10
|
Ed Schofield <schofield <at> ftw.at> writes: > > > On 08/07/2006, at 10:22 PM, JJ wrote: > > > 3) In some operations, especially range selection operations, a N, > > 1 matrix is > > turned into a 1,N matrix. This is confusing relative to matlab and > > problematic, > > in my view. > > This sounds like a bug. Can you give any examples of this happening > with the latest release or SVN version? > > > <snip> > > > > 5) If X is a 1,n matrix, then X.T should return a n,1 matrix, I > > think. > > This should be the case. Could you post a code snippet that violates > it? > > Thanks for your feedback, JJ! >-------------------------------------------------- Hi Ed: Here are a couple more items: c = cov(a) # a is a matrix type(c) # should be a matrix <type 'numpy.ndarray'> Also, if a is 5x2, then cov(a) is 5,5. Is that just a convention? I would expect the cov to be 2,2, as in matlab. It means I have to use more transpose methods. D is a 1,n matrix (D<2).nonzero()[0] As per my earlier comment on which(), I wish that .nonzero() did not return a tupple. |
|
From: Jonathan T. <jon...@ut...> - 2006-07-11 20:07:48
|
I agree the real problem with matrices is they seem awkward to work
with compared to arrays because numpy seems so array centric. The
only advantage I see is getting .T to do transposes and * to do matrix
multiplication. I hope numpy reaches a point where it is as natural
to use matrices as arrays. I'd also vote for the inclusion of the
following two functions col and row. Inspired by R equivelents they
let you do some indexing very easily such as getting the values of the
upper triangle of the matrix. E.g.
vals = m[row(m) > col(m)]
Cheers,
Jon.
def col(m):
"""col(m) returns a matrix of the same size of m where each element
contains an integer denoting which column it is in. For example,
>>> m = eye(3)
>>> m
array([[1, 0, 0],
[0, 1, 0],
[0, 0, 1]])
>>> col(m)
array([[0, 1, 2],
[0, 1, 2],
[0, 1, 2]])
"""
assert len(m.shape) == 2, "should be a matrix"
return N.indices(m.shape)[1]
def row(m):
"""row(m) returns a matrix of the same size of m where each element
contains an integer denoting which row it is in. For example,
>>> m = eye(3)
>>> m
array([[1, 0, 0],
[0, 1, 0],
[0, 0, 1]])
>>> row(m)
array([[0, 0, 0],
[1, 1, 1],
[2, 2, 2]])
"""
assert len(m.shape) == 2, "should be a matrix"
return N.indices(m.shape)[0]
On 7/7/06, Ed Schofield <sch...@ft...> wrote:
> Bill Baxter wrote:
> > I think the thread to this point can be pretty much summarized by:
> >
> > while True:
> > Bill: "2D transpose is common so it should have a nice syntax"
> > Tim, Robert, Sasha, and Ed: "No it's not."
> >
> > Very well. I think it may be a self fulfilling prophecy, though.
> > I.e. if matrix operations are cumbersome to use, then -- surprise
> > surprise -- the large user base for matrix-like operations never
> > materializes. Potential converts just give numpy the pass, and go to
> > Octave or Scilab, or stick with Matlab, R or S instead.
> >
> > Why all the fuss about the .T? Because any changes to functions (like
> > making ones() return a matrix) can easily be worked around on the user
> > side, as has been pointed out. But as far as I know -- do correct me
> > if I'm wrong -- there's no good way for a user to add an attribute to
> > an existing class. After switching from matrices back to arrays, .T
> > was the only thing I really missed from numpy.matrix.
> >
> > I would be all for a matrix class that was on equal footing with array
> > and as easy to use as matrices in Matlab. But my experience using
> > numpy.matrix was far from that, and, given the lack of enthusiasm for
> > matrices around here, that seems unlikely to change. However, I'm
> > anxious to see what Ed has up his sleeves in the other thread.
>
> Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;)
> I'd like to know why you, Sven, and anyone else on the list have gone
> back to using arrays after trying matrices. What was inconvenient about
> them? I'd like a nice juicy list. The whole purpose of the matrix
> class is to simplify 2d linear algebra. Where is it failing?
>
> I also went back to arrays after trying out matrices for some 2d linear
> algebra tasks, since I found that using matrices increased my code's
> complexity. I can describe the problems I had with them later, but
> first I'd like to hear of others' experiences.
>
> I'd like to help to make matrices more usable. Tell me what you want,
> and I'll work on some patches.
>
> -- Ed
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X