[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