On Wed, Apr 28, 2010 at 10:08 AM, Dag Sverre Seljebotn < [email protected]> wrote:
> 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. > > Yeah. Masked arrays have similar problems. Pierre has done so much work to have masked versions of the various functions that it might as well be a standalone class. <snip> Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
