[Numpy-discussion] add .H attribute?

[Dag Sverre Seljebotn]

On 07/23/2013 10:35 AM, Dag Sverre Seljebotn wrote:
> 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.

Sorry: I'm +1 on another name for a method that does a copy. Which can 
eventually be made redundant with A.H.copy(), if somebody ever takes on 
the work to make that happen...but at least I think the path to that 
should be kept open.

Dag Sverre