> 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. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion