[Numpy-discussion] deprecate numpy.matrix
argriffi at ncsu.edu
Tue Feb 11 14:20:10 EST 2014
On Tue, Feb 11, 2014 at 12:05 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Tue, Feb 11, 2014 at 8:55 AM, <josef.pktd at gmail.com> wrote:
>> On Tue, Feb 11, 2014 at 11:25 AM, Matthew Brett <matthew.brett at gmail.com>
>>> On Tue, Feb 11, 2014 at 4:16 AM, Jacco Hoekstra - LR
>>> <J.M.Hoekstra at tudelft.nl> wrote:
>>> > For our students, the matrix class is really appealing as we use a lot
>>> > of linear algebra and expressions with matrices simply look better with an
>>> > operator instead of a function:
>>> > x=A.I*b
>>> > looks much better than
>>> > x = np.dot(np.linalg.inv(A),b)
>>> Yes, but:
>>> 1) as Alan has mentioned, the dot method helps a lot.
>>> import numpy.linalg as npl
>>> x = npl.inv(A).dot(b)
>>> 2) Overloading the * operator means that you've lost * to do
>>> element-wise operations. MATLAB has a different operator for that,
>>> '.*' - and it's very easy to forget the dot. numpy makes this more
>>> explicit - you read 'dot' as 'dot'.
>>> > And this gets worse when the expression is longer:
>>> > x = R.I*A*R*b
>>> > becomes:
>>> > x = np.dot( np.linalg.inv(R), np.dot(A, np.dot(R, b)))
>>> x = npl.inv(R).dot(A.dot(R.dot(b))
>>> > Actually, not being involved in earlier discussions on this topic, I was
>>> > a bit surprised by this and do not see the problem of having the matrix
>>> > class as nobody is obliged to use it. I tried to find the reasons, but did
>>> > not find it in the thread mentioned. Maybe someone could summarize the main
>>> > problem with keeping this class for newbies on this list like me?
>>> > 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
>> selection bias !
>> I have seen lots of Matlab and GAUSS code written by academic
>> econometricians that have been programming for years but are not
>> "developers", code that is "inefficient" and numerically not very stable but
>> looks just like the formulas.
> Yes, I used to use matlab myself.
> There is certainly biased sampling on this list, so it's very
> difficult to say whether there is a large constituency of np.matrix
> users out there, it's possible. I hope not, because I think they
> would honestly be better served with ndarray even if some of the lines
> in their script don't look quite as neat.
In the spirit of offsetting this bias and because this thread is
lacking in examples of projects that use numpy.matrix, here's another
data point: cvxpy (https://github.com/cvxgrp/cvxpy) is a serious
active project that supports the numpy.matrix interface, for example
as in https://github.com/cvxgrp/cvxpy/tree/master/cvxpy/interface/numpy_interface.
This project is from a somewhat famous Stanford lab
(http://www.stanford.edu/~boyd/index.html) and they are currently
running a MOOC (http://en.wikipedia.org/wiki/Massive_open_online_course)
for convex optimization
This course currently uses a MATLAB-based modeling system
(http://cvxr.com/cvx/) but they are trying to switch to, or at least
support, Python. But they have not yet been able to get cvxpy to a
mature enough state to use for their course. Maybe the simple
numpy.matrix syntax has accelerated their progress so that they have
been able to reach cvxpy's currently somewhat usable state, or maybe
the extra work to deal with numpy.matrix has slowed their progress so
that we are using MATLAB instead of Python as the standard for
training Stanford undergrads and random internet MOOC participants, or
maybe their progress has little to do with numpy.matrix. I'm not sure
which is the case. But in any case, they use numpy.matrix explicitly
in their project.
More information about the NumPy-Discussion