[Numpy-discussion] deprecate numpy.matrix

Chris Barker chris.barker at noaa.gov
Tue Feb 11 12:14:33 EST 2014

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.

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...

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140211/8dec2df9/attachment.html>

More information about the NumPy-Discussion mailing list