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