[Numpy-discussion] add .H attribute?

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Tue Jul 23 04:36:33 EDT 2013

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

More information about the NumPy-Discussion mailing list