On Jul 23, 2013, at 11:54 PM, "Stéfan van der Walt" <ste...@sun.ac.za> wrote:
>>> The .H property has been implemented in Numpy matrices and Scipy's >>> sparse matrices for many years. >> >> Then we're done. Numpy is an array package, NOT a matrix package, and >> while you can implement matrix math with arrays (and we do), having >> quick and easy mnemonics for common matrix math operations (but >> uncommon general purpose array operations) is not eh job of numpy. >> That's what the matrix object is for. > > I would argue that the ship sailed when we added .T already. Most > users see no difference between the addition of .T and .H. I don't know who can speak for "most users", but I see them quite differently. Transposing is a common operation outside of linear algebra--I, for one, use it to work with image arrays, which are often stored in a way by image libraries that is the transpose of the "natural" numpy way. But anyway, just because we have one domain-specific convenience attribute, doesn't mean we should add them all. > The matrix class should probably be deprecated and removed from NumPy > in the long run--being a second class citizen not used by the > developers themselves is not sustainable. I agree, but the fact that no one has stepped up to maintain and improve it tells me that there is not a very large community that wants a clean linear algebra interface, not that we should try to build such an interface directly into numpy. Is there really a point to a clean interface to the Hermetian transpose, but not plain old matrix multiply? > And, now that we have "dot" > as a method, Agh, but "dot" is a method--so we still don't have a clean relationship with the math in text books: AB => A.dot(B) Anyway, adding .H is clearly not a big deal, I just don't think it's going to satisfy anyone anyway. -Chris _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
