[Numpy-discussion] matrix wart

Travis E. Oliphant oliphant@enthought....
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[0] 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[0][0] 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[0][0] 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[0][0] 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.

-Travis O. 




More information about the Numpy-discussion mailing list