[Numpy-discussion] proposing a "beware of [as]matrix()" warning

Dag Sverre Seljebotn dagss@student.matnat.uio...
Wed Apr 28 11:08:03 CDT 2010


David Warde-Farley wrote:
> Trying to debug code written by an undergrad working for a colleague of 
> mine who ported code over from MATLAB, I am seeing an ugly melange of 
> matrix objects and ndarrays that are interacting poorly with each other 
> and various functions in SciPy/other libraries. In particular there was 
> a custom minimizer function that contained a line "a * b", that was 
> receiving an Nx1 "matrix" and a N-length array and computing an outer 
> product. Hence the unexpected 6 GB of memory usage and weird results...

If this was in a library function of some sort, I think they should 
always call np.asarray on the input arguments. That converts matrices to 
normal arrays.

It could have been Python lists-of-lists, other PEP 3118 objects -- in 
Python an object can be everything in general, and I think it is very 
proper for most reusable functions to either validate the type of their 
arguments or take some steps to convert.

That said, I second that it would be good to deprecate the matrix class 
from NumPy. The problem for me is not the existance of a matrix class as 
such, but the fact that it subclasses np.ndarray and is so similar with 
it, breaking a lot of rules for OO programming in the process.

(Example: I happen to have my own oomatrix.py which allows me to do

P, L = (A * A.H).cholesky()
y = L.solve_right(x)

This works fine because the matrices don't support any NumPy operations, 
and so I don't confuse them. But it helps to have to habit to do 
np.asarray in reusable functions so that errors are caught early.

I do this so that A above can be either sparse, dense, triangular, 
diagonal, etc. -- i.e. polymorphic linear algebra. On the other hand, 
they don't even support single-element lookups, although that's just 
because I've been to lazy to implement it. Iteration is out of the 
question, it's just not the level of abstraction I'd like a "matrix" to 
work at.)

Dag Sverre

> 
> We've had this discussion before and it seems that the matrix class 
> isn't going anywhere (I *really* wish it would at least be banished from 
> the top-level namespace), but it has its adherents for pedagogical 
> reasons. Could we at least consider putting a gigantic warning on all 
> the functions for creating matrix objects (matrix, mat, asmatrix, etc.) 
> that they may not behave quite so predictably in some situations and 
> should be avoided when writing nontrivial code?
> 
> There are already such warnings scattered about on SciPy.org but the 
> situation is so bad, in my opinion (bad from a programming perspective 
> and bad from a new user perspective, asking "why doesn't this work? why 
> doesn't that work? why is this language/library/etc. so stupid, 
> inconsistent, etc.?") that the situation warrants steering people still 
> further away from the matrix object.
> 
> I apologize for ranting, but it pains me when people give up on 
> Python/NumPy because they can't figure out inconsistencies that aren't 
> really there for a good reason. IMHO, of course.
> 
> David
> 
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion


-- 
Dag Sverre


More information about the NumPy-Discussion mailing list