# [Numpy-discussion] deprecate numpy.matrix

Matthew Brett matthew.brett at gmail.com
Tue Feb 11 12:05:06 EST 2014

```Hi,

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>
> wrote:
>>
>> Hi,
>>
>> 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
>> cost.
>
>
> 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.

But in any case, I still don't think that dropping np.matrix is an
option in the short or even the medium term.  The discussion - I think
- is whether we should move towards standardizing to ndarray semantics
for clarity and simplicity of future development (and teaching),

Cheers,

Matthew

```