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.