[Numpy-discussion] add .H attribute?

[josef.pktd at gmail.com]

I think a H is feature creep and too specialized

What's .H of a int a str a bool ?

It's just .T and a view, so you cannot rely that conj() makes a copy
if you don't work with complex.

.T is just a reshape function and has **nothing** to do with matrix algebra.


>>> x = np.arange(12).reshape(3,4)
>>> x
array([[ 0,  1,  2,  3],
       [ 4,  5,  6,  7],
       [ 8,  9, 10, 11]])
>>> np.may_share_memory(x, x.T)
True
>>> np.may_share_memory(x, x.conj())
True
>>> y = x + 1j
>>> np.may_share_memory(y, y.conj())
False
>>> y.dtype
dtype('complex128')
>>> x.conj().dtype
dtype('int32')

Josef

On Wed, Jul 24, 2013 at 3:30 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
> On Wed, Jul 24, 2013 at 9:15 AM, Sebastian Haase <seb.haase at gmail.com> wrote:
>> I feel that adding a method
>> .H()
>> would be the compromise !
>
> Thinking about this more, I think it would just confuse most users...
> why .T and not .H; then you have to start explaining the underlying
> implementation detail.  For users who already understand the
> implementation detail, finding .T.conj() would not be too hard.
>
>> (( 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))
>
> I am willing to write up a NEP if there's any interest.  The plan
> would be to remove the Matrix class from numpy over two or three
> releases, and publish it as a separate package on PyPi.
>
> Stéfan
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion