I noticed that the mean of a matrix is a matrix but the standard deviation of a matrix is an array. Is that the expected behavior? I'm also getting the wrong values (0 and nan) for the standard deviation. Did I mess something up? I'm trying to learn scipy (and python) by porting a small Octave program. I installed numpy from svn (today) on a Debian box. And numpy.test() says OK. Here's an example:
numpy.__version__ '0.9.7.2416'
x = asmatrix(random.uniform(0,1,(3,3)))
x
matrix([[ 0.56771284, 0.57053769, 0.57505946], [ 0.10479534, 0.81692248, 0.91829316], [ 0.48627829, 0.59255983, 0.32628573]])
x.mean(0) matrix([[ 0.38626216, 0.66000667, 0.60654612]])
x.std(0) array([ nan, 0. , 0. ])
Keith Goodman wrote:
I noticed that the mean of a matrix is a matrix but the standard deviation of a matrix is an array. Is that the expected behavior? I'm also getting the wrong values (0 and nan) for the standard deviation. Did I mess something up?
I'm trying to learn scipy (and python) by porting a small Octave program. I installed numpy from svn (today) on a Debian box. And numpy.test() says OK.
This should be fixed now in SVN. If somebody can add a test that would be great. Note, that the methods taking axes also now preserve row and column orientation for matrices. -Travis
On a slightly-related note, was anyone able to reproduce the exception with matrix types and the var() method? e.g. numpy.matrix([[1,2,3], [1,2,3]]).var() complains about unaligned data... Presumably if std is fixed in SVN, so is var. Also if a std unit test is added, a var one should be too. Zach On Apr 27, 2006, at 12:51 AM, Travis Oliphant wrote:
Keith Goodman wrote:
I noticed that the mean of a matrix is a matrix but the standard deviation of a matrix is an array. Is that the expected behavior? I'm also getting the wrong values (0 and nan) for the standard deviation. Did I mess something up?
I'm trying to learn scipy (and python) by porting a small Octave program. I installed numpy from svn (today) on a Debian box. And numpy.test() says OK.
This should be fixed now in SVN. If somebody can add a test that would be great.
Note, that the methods taking axes also now preserve row and column orientation for matrices.
-Travis
------------------------------------------------------- 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Travis Oliphant wrote:
Keith Goodman wrote:
I noticed that the mean of a matrix is a matrix but the standard deviation of a matrix is an array. Is that the expected behavior? I'm also getting the wrong values (0 and nan) for the standard deviation. Did I mess something up? This should be fixed now in SVN. If somebody can add a test that would be great.
Note, that the methods taking axes also now preserve row and column orientation for matrices.
Well done for doing this. In fact, you beat me to it by a few hours; I was going to post a patch this morning to preserve orientation with matrix operations. The approach I took was different in one respect. Matrix objects currently return a matrix of shape (1, 1) from methods with an axis=None argument. For example:
x = asmatrix(random.uniform(0,1,(3,3))) x.std() matrix([[ 0.26890557]])
x.argmax() matrix([[4]])
I believe this behaviour is unfortunate, and that an operation aggregating a matrix over all dimensions should return a scalar. I've posted a patch at http://projects.scipy.org/scipy/numpy/ticket/83 that modifies this behaviour to return scalars (as rank-0 arrays) instead. It also removes some code duplication. The behaviour with the patch is:
x.std() 0.29610630190701492
x.std().shape ()
x.argmax() 3
Returning scalars from methods with an axis=None argument is the current behaviour of scipy sparse matrices, while axis=0 or axis=1 yields a sparse matrix with height or width 1, like numpy matrices. A (1 x 1) sparse matrix would be a strange object indeed, and would not be usable in all contexts where scalars are expected. I suspect the same would hold for (1 x 1) dense matrices. One example is that they cannot be used as indices for Python lists. For some matrix methods, such as argmax, returning a scalar would be highly desirable by allowing simpler code. A potential drawback to this change is that matrix operations aggregating along all dimensions, which would now share the behaviour of numpy arrays, would be no longer be consistent with matrix operations that aggregate along only one dimension, which currently do not reduce dimension, because matrices are inherently 2-d. This could be an argument for introducing a new vector class to represent one-dimensional data with orientation. -- Ed
Ed Schofield wrote:
Travis Oliphant wrote:
Keith Goodman wrote:
I noticed that the mean of a matrix is a matrix but the standard deviation of a matrix is an array. Is that the expected behavior? I'm also getting the wrong values (0 and nan) for the standard deviation. Did I mess something up?
This should be fixed now in SVN. If somebody can add a test that would be great.
Note, that the methods taking axes also now preserve row and column orientation for matrices.
Well done for doing this.
In fact, you beat me to it by a few hours; I was going to post a patch this morning to preserve orientation with matrix operations. The approach I took was different in one respect.
I like your function-call approach as it ensures consistent behavior.
Returning scalars from methods with an axis=None argument is the current behaviour of scipy sparse matrices, while axis=0 or axis=1 yields a sparse matrix with height or width 1, like numpy matrices. A (1 x 1) sparse matrix would be a strange object indeed, and would not be usable in all contexts where scalars are expected. I suspect the same would hold for (1 x 1) dense matrices. One example is that they cannot be used as indices for Python lists. For some matrix methods, such as argmax, returning a scalar would be highly desirable by allowing simpler code.
A potential drawback to this change is that matrix operations aggregating along all dimensions, which would now share the behaviour of numpy arrays, would be no longer be consistent with matrix operations that aggregate along only one dimension, which currently do not reduce dimension, because matrices are inherently 2-d. This could be an argument for introducing a new vector class to represent one-dimensional data with orientation.
There is one more problem in that matrix-operations will not be preserved in all cases as they would have before. However, I suppose somebody doing a reduce over all dimensions would probably not expect the result to be a matrix, so I don't think it's a big drawback. Consistency with sparse matrices is another reason for returning a scalar. -Travis
participants (5)
-
Ed Schofield -
Keith Goodman -
Travis Oliphant -
Travis Oliphant -
Zachary Pincus