[Numpy-discussion] add .H attribute?

[Dag Sverre Seljebotn]

On 07/23/2013 09:35 AM, Dave Hirschfeld wrote:
> Alan G Isaac <alan.isaac <at> gmail.com> writes:
>
>>
>> On 7/22/2013 3:10 PM, Nathaniel Smith wrote:
>>> Having .T but not .H is an example of this split.
>>
>> Hate to do this but ...
>>
>>    Readability counts.
>
> +10!
>
> A.conjugate().transpose() is unspeakably horrible IMHO. Since there's no way
> to avoid a copy you gain nothing by not providing the convenience function.
>
> It should be fairly obvious that an operation which changes the values of an
> array (and doesn't work in-place) necessarily takes a copy. I think it's more
> than sufficient to simply document the fact that A.H will return a copy.

I don't think this is obvious at all. In fact, I'd fully expect A.H to 
return a view that conjugates the values on the fly as they are 
read/written (just the same way the array is "transposed on the fly" or 
"sliced on the fly" with other views).

There's lots of uses for A.H to be a conjugating-view, e.g., np.dot(A.H, 
A) can be done on-the-fly by BLAS at no extra cost, and so on. These are 
currently not possible with pure NumPy without a copy, which is a pretty 
big defect IMO (and one reason I'd call BLAS myself using Cython rather 
than use np.dot...)

So -1 on using A.H for anything but a proper view, and "A.conjt()" or 
something similar for a method that does a copy.

Dag Sverre