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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dag Sverre _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
