[Numpy-discussion] deprecate numpy.matrix

[josef.pktd at gmail.com]

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
>> 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.Barker at noaa.gov
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140211/2612b155/attachment.html>