[Numpy-discussion] add .H attribute?

Chris Barker - NOAA Federal chris.barker at noaa.gov
Wed Jul 24 11:24:00 EDT 2013


On Jul 23, 2013, at 11:54 PM, "Stéfan van der Walt" <stefan at 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



More information about the NumPy-Discussion mailing list