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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion