On Tue, Apr 29, 2008 at 12:22:18PM -0700, Timothy Hochberg wrote: > First, there seems to be disagreement about what a row_vector and > column_vector are (and even if they are sensible concepts, but let's leave > that aside for moment). One school of thought is that they are > one-dimensional objects that have some orientation (hence row/column). > They correspond, more or less, to covariant and contravariant tensors, > although I can never recall which is which. The second view, which I > suspect is influenced by MatLab and its ilk, is that they are > 2-dimensional 1xN and Nx1 arrays. It's my view that the pseudo tensor > approach is more powerful, but it does require some metainformation be > added to the array. This metadata can either take the form of making the > different objects different classes, which leads to the matrix/row/column > formulation, or adding some sort of tag to the array object (proposal #5, > which so far lacks any detail).
Good summary. I support the 1D object with orientation, rather than the 2D object with special indexing. I would call the row_vector/column_vectors bras and kets rather than tensors, but that because I come from a quantum mechanics background. > Second, most of the stuff that we have been discussing so far is primarily > about notational convenience. However, there is matrix related stuff that > is at best poorly supported now, namely operations on stacks of arrays (or > vectors). As a concrete example, I at times need to work with stacks of > small matrices. If I do the operations one by one, the overhead is > prohibitive, however, most of that overhead can be avoided. For example, I > rewrote some of the linalg routines to work on stacks of matrices and > inverse is seven times faster for a 100x10x10 array (a stack of 100 10x10 > matrices) when operating on a stack than when operating on the matrices > one at a time. This is a result of sharing the setup overhead, the C > routines that called are the same in either case. Good point. Do you have an idea to move away from this problem? Gaël _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
