# [Numpy-discussion] What's wrong with matrices?

Jonathan Taylor jonathan.taylor at utoronto.ca
Tue Jul 11 15:07:40 CDT 2006

```I agree the real problem with matrices is they seem awkward to work
with compared to arrays because numpy seems so array centric.  The
only advantage I see is getting .T to do transposes and * to do matrix
multiplication.  I hope numpy reaches a point where it is as natural
to use matrices as arrays.  I'd also vote for the inclusion of the
following two functions col and row.  Inspired by R equivelents they
let you do some indexing very easily such as getting the values of the
upper triangle of the matrix.  E.g.

vals = m[row(m) > col(m)]

Cheers,
Jon.

def col(m):
"""col(m) returns a matrix of the same size of m where each element
contains an integer denoting which column it is in.  For example,

>>> m = eye(3)
>>> m
array([[1, 0, 0],
[0, 1, 0],
[0, 0, 1]])
>>> col(m)
array([[0, 1, 2],
[0, 1, 2],
[0, 1, 2]])
"""
assert len(m.shape) == 2, "should be a matrix"
return N.indices(m.shape)[1]

def row(m):
"""row(m) returns a matrix of the same size of m where each element
contains an integer denoting which row it is in.  For example,

>>> m = eye(3)
>>> m
array([[1, 0, 0],
[0, 1, 0],
[0, 0, 1]])
>>> row(m)
array([[0, 0, 0],
[1, 1, 1],
[2, 2, 2]])

"""
assert len(m.shape) == 2, "should be a matrix"
return N.indices(m.shape)[0]

On 7/7/06, Ed Schofield <schofield at ftw.at> wrote:
> Bill Baxter wrote:
> > I think the thread to this point can be pretty much summarized by:
> >
> > while True:
> >     Bill: "2D transpose is common so it should have a nice syntax"
> >     Tim, Robert, Sasha, and Ed: "No it's not."
> >
> > Very well.  I think it may be a self fulfilling prophecy, though.
> > I.e. if matrix operations are cumbersome to use, then -- surprise
> > surprise -- the large user base for matrix-like operations never
> > materializes.  Potential converts just give numpy the pass, and go to
> > Octave or Scilab, or stick with Matlab, R or S instead.
> >
> > Why all the fuss about the .T?  Because any changes to functions (like
> > making ones() return a matrix) can easily be worked around on the user
> > side, as has been pointed out.  But as far as I know -- do correct me
> > if I'm wrong -- there's no good way for a user to add an attribute to
> > an existing class.  After switching from matrices back to arrays, .T
> > was the only thing I really missed from numpy.matrix.
> >
> > I would be all for a matrix class that was on equal footing with array
> > and as easy to use as matrices in Matlab.  But my experience using
> > numpy.matrix was far from that, and, given the lack of enthusiasm for
> > matrices around here, that seems unlikely to change.  However, I'm
> > anxious to see what Ed has up his sleeves in the other thread.
>
> Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;)
> I'd like to know why you, Sven, and anyone else on the list have gone
> back to using arrays after trying matrices.  What was inconvenient about
> them?  I'd like a nice juicy list.  The whole purpose of the matrix
> class is to simplify 2d linear algebra.  Where is it failing?
>
> I also went back to arrays after trying out matrices for some 2d linear
> algebra tasks, since I found that using matrices increased my code's
> complexity.  I can describe the problems I had with them later, but
> first I'd like to hear of others' experiences.
>
> I'd like to help to make matrices more usable.  Tell me what you want,
> and I'll work on some patches.
>
> -- Ed
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier