On Wed, Jul 24, 2013 at 8:53 AM, Stéfan van der Walt <ste...@sun.ac.za> wrote: > On Wed, Jul 24, 2013 at 2:15 AM, Chris Barker - NOAA Federal > <chris.bar...@noaa.gov> wrote: >> >> On Tue, Jul 23, 2013 at 6:09 AM, Pauli Virtanen <p...@iki.fi> 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. > > 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. And, now that we have "dot" > as a method, there's very little advantage to it. > > Stéfan
Maybe this is the point where one just needs to do a poll. And finally someone has to make the decision. I feel that adding a method .H() would be the compromise ! Alan, could you live with that ? It is short enough and still emphasises the fact that it is NOT a view and therefore behaves sensitively different in certain scenarios as .T . It also leaves the door open to adding an iterator .H attribute later on without introducing the above mentioned code breaks. Who could make (i.e. is willing to make) the decision ? (( I would not open the discussion about ndarray vs. matrix -- it gets far to involving and we would be talking about far-future directions instead of "a single letter addition", which abvious already has big enough support and had so years ago)) Regards, Sebastian Haase _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
