On Tue, Feb 11, 2014 at 12:14 PM, Chris Barker <chris.bar...@noaa.gov>wrote:
> On Tue, Feb 11, 2014 at 8:25 AM, Matthew Brett <matthew.br...@gmail.com>wrote: > >> > Anyway, I would say that there is a clear use for the matrix class: >> readability of linear algebra code and hence a lower chance of errors, so >> higher productivity. >> >> Yes, but it looks like there are not any developers on this list who >> write substantial code with the np.matrix class, so, if there is a >> gain in productivity, it is short-lived, soon to be replaced by a >> cost. >> > > to re-iterate: > > matrix is NOT for newbies, nor is it for higher productivity or fewer > errors in production code -- the truth is, the ratio of linear algebra > expressions like the above to element-wise, etc. operations that ndarray is > well suited to is tiny in "real" code. Did anyone that used MATLAB for > significant problems get not get really really annoyed by all the typing of > ".*" ? > > What matrix is good for is what someone here described as "domain specific > language" -- i.e. that little bit of code that really is > doing mostly linera algebra. So it's a nice tool for teaching and > experimenting with linear-algebra-based concepts. > http://www.mathworks.com/matlabcentral/fileexchange/27095-tsls-2sls/content/tsls.m https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/regression/gmm.py#L134 If I were not strict ndarray coder, I might prefer to wrap an ndarray and use only matrices inside a function and ndarrays outside for the code that is not linear algebra. > > To address Alan's question about duck-typing -- one of the things folks > like to do with duck-typed functions and method is return the type that is > passed in when possible: i.e use asanyarray(), rather than asarray() -- but > this is really going to be broken with matrix, as the symantics have > changed. So we could say "don't expect that to work with matrix", but that > requires one of: > > 1) folks always use asarray() and return an array, rather than a matrix to > the caller -- not too bad, folks that want matrix can use np.matrix to get > it back (a bit ugly, though..) however, this means that any other array > subclass will get mangled as well... > scipy.linalg has an arraywrap on input and output. (at least when I looked a few years ago) (statsmodels has a pandas wrapper that converts arguments and returns to have ndarrays internally) some packages have helper functions to make a consistent interface to ndarrays and sparce "matrices" scipy.stats still doesn't protect against masked arrays and nans. IMO: that's life. Removing matrices from numpy doesn't make the problem go away. Although the problem could be pushed to other packages. But if nobody uses matrices, then we would have at least **one** problem less. > > 2) folks use asanyarray(), and it will break, maybe painfully, when a > matrix is passed in -- folks using matrixes would need to use .A when > calling such functions. This really seems ripe for confusion. > There are many ndarray subclasses out there, and I have no idea how they behave. pandas.Series was until recently a ndarray subclass, that didn't quite behave like one. We had to fix some bugs in statsmodels where we accidentially use asanyarray instead of asarray. Josef > > The truth is that the "right" way to do all this is to > have different operators, rather than different objects, but that's been > tried and did not fly. > > -Chris > > > > > > > > > > > > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion