[Numpy-discussion] add .H attribute?

[Nathaniel Smith]

On Tue, Jul 23, 2013 at 9:35 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> 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...)

I was skeptical about this at first on the grounds that yeah, it'd be
nice if at some point we allowed for on-the-fly transformations, it
isn't happening anytime soon.

But on second thought, we actually could implement this pretty easily
-- just define a new dtype "conjcomplex" that stores the value x+iy as
two doubles (x, -y). Then
  complex_arr.view(conjcomplex)
would preserve memory contents but invert the numeric sign of all
imaginary components, while
  complex_arr.astype(conjcomplex)
would preserve numeric value but alter the memory representation.
Because this latter cast is safe, all the existing ufuncs would
automatically work fine on conjcomplex arrays. But we could also
define conjcomplex-specific ufunc loops for cases like dot() where a
more efficient implementation is possible (using the above-mentioned
BLAS flags).

Don't know if we want to actually do this, but it's doable.

(I don't have any in-principle objection to .H(), but won't it just
lead to more threads complaining about how confusing it is that .T and
.H() are different?)

-n