<p dir="ltr">On 13 Jul 2013 16:30, "Alan G Isaac" <<a href="mailto:alan.isaac@gmail.com">alan.isaac@gmail.com</a>> wrote:<br>
><br>
> > On Sun, Jul 7, 2013 at 9:28 AM, Alan G Isaac <<a href="mailto:alan.isaac@gmail.com">alan.isaac@gmail.com</a> <mailto:<a href="mailto:alan.isaac@gmail.com">alan.isaac@gmail.com</a>>> wrote:<br>
> > I miss being able to spell a.conj().T as a.H, as one can<br>
> > with numpy matrices.<br>
><br>
><br>
> On 7/7/2013 4:49 PM, Charles R Harris wrote:<br>
> > There was a long thread about this back around 1.1 or so,<br>
> > long time ago in any case. IIRC correctly, Travis was<br>
> > opposed. I think part of the problem was that arr.T is<br>
> > a view, but arr.H would not be. Probably it could be be<br>
> > made to return an iterator that performed the conjugation,<br>
> > or we could simply return a new array. I'm not opposed<br>
> > myself, but I'd have to review the old discussion to see<br>
> > if there was good reason not to have it in the first<br>
> > place. I think the original discussion of an abs method<br>
> > took place about the same time.<br>
><br>
><br>
> If not being a view is determinative, could a .ct() method<br>
> be considered?  Or would the objection apply there too?</p>
<p dir="ltr">Why not just write</p>
<p dir="ltr">def H(a):<br>
    return a.conj().T</p>
<p dir="ltr">in your local namespace? The resulting code will be even more concise than if we had a .ct() method.</p>
<p dir="ltr">ndarray has way too many attributes already IMHO (though I realize this may be a minority view).</p>
<p dir="ltr">-n</p>