[Numpy-discussion] add .H attribute?
seb.haase at gmail.com
Wed Jul 24 03:15:56 EDT 2013
On Wed, Jul 24, 2013 at 8:53 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
> On Wed, Jul 24, 2013 at 2:15 AM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>> On Tue, Jul 23, 2013 at 6:09 AM, Pauli Virtanen <pav at 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.
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
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))
More information about the NumPy-Discussion