[Numpy-discussion] matrix wart
Travis E. Oliphant
Fri Feb 22 09:18:38 CST 2008
> On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
>> This is exactly what I would expect for matrices: M is
>> the first row of the matrix.
> Define what "first row" means!
Konrad has shown that do "get it right" you really have to introduce
three separate things (matrices, row vectors, and column vectors).
This is a fine direction to proceed in, but it does complicate things as
well. The current implementation has the advantage that row vectors
are just 1xN matrices and column vectors are Nx1 matrices, so there is
only 1 kind of thing: matrices.
The expectation that M and M[0,0] return the same thing stems from
believing that all objects using  syntax are just containers.
(Think of a dictionary with keys, '0', and '(0,0)' for an example). The
matrix object is not a "container" object. A NumPy array, however, is.
They have different behaviors, on purpose. If you don't like the matrix
object, then just use the NumPy array. There are situations, however,
when the matrix object is very useful. I use it in limited fashion to
make expressions easier to read.
> Imagine if a 2d array behaved this way. Ugh!
> Note that it too is 2d; you could have the same
> "expectation" based on its 2d-ness. Why don't you?
The 2d-ness is not the point. The point is that a matrix object is a
matrix object and *not* a generic container.
> Nobody has objected to returning matrices when getitem is
> fed multiple arguments: these are naturally interpreted as
> requests for submatrices. M and M[:1,:1] are very
> different kinds of requests: the first should return the 0,0
> element but does not, while M[0,0] does! Bizarre!
> How to guess?? If you teach, do your students expect this
> behavior? Mine don't!
Again, stop believing that M and M[0,0] should return the same
thing. There is nothing in Python that requires this.
As far as I know, the matrix object is consistent. It may not behave as
you, or people that you teach, would expect, but it does have reasonable
behavior. Expectations are generally "learned" based on previous
experience. Our different experiences will always lead to different
expectations. What somebody expects for a matrix behavior will depend
on how they were taught what it means to "be" a matrix.
> This is a wart.
I disagree. It's not a wart, it is intentional.
> The example really speaks for itself. Since Konrad is an
> extremely experienced user/developer, his reaction should
> speak volumes.
I'm not as convinced by this kind of argument. I respect Konrad a great
deal and am always interested to hear his opinion, and make use of all
of the code that he shares with us. His example has been an important
part of my Python "education." However, we do approach problems
differently (probably again based on previous experiences) which leads
us to promote different solutions. I also see this in the wider
Python community where there is a "diversity" of user/developers who
promote different approaches as well (e.g. the PIL vs NumPy concept of
Images comes to mind as well).
I've heard many differing points of view on the Matrix object.
Stefan's comment is most relevant: the Matrix object can be changed (in
1.1), especially because we are keen on merging CVXOPT's matrix object
with NumPy's and making it a builtin type.
More information about the Numpy-discussion