[Numpy-discussion] deprecate numpy.matrix
josef.pktd at gmail.com
josef.pktd at gmail.com
Tue Feb 11 12:55:22 EST 2014
On Tue, Feb 11, 2014 at 12:14 PM, Chris Barker <chris.barker at noaa.gov>wrote:
> On Tue, Feb 11, 2014 at 8:25 AM, Matthew Brett <matthew.brett at 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
> 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.
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
> 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
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.
> 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.
> Christopher Barker, Ph.D.
> 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.Barker at noaa.gov
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion