On Tue, Jun 25, 2019 at 4:29 AM Cameron Blocker <cameronjbloc...@gmail.com> wrote: > > In my opinion, the matrix transpose operator and the conjugate transpose > operator should be one and the same. Something nice about both Julia and > MATLAB is that it takes more keystrokes to do a regular transpose instead of > a conjugate transpose. Then people who work exclusively with real numbers can > just forget that it's a conjugate transpose, and for relatively simple > algorithms, their code will just work with complex numbers with little > modification. >
I'd argue that MATLAB's feature of `'` meaning adjoint (conjugate transpose etc.) and `.'` meaning regular transpose causes a lot of confusion and probably a lot of subtle bugs. Most people are unaware that `'` does a conjugate transpose and use it habitually, and when for once they have a complex array they don't understand why the values are off (assuming they even notice). Even the MATLAB docs conflate the two operations occasionally, which doesn't help at all. Transpose should _not_ incur conjugation automatically. I'm already a bit wary of special-casing matrix dynamics this much, when ndarrays are naturally multidimensional objects. Making transposes be more than transposes would be a huge mistake in my opinion, already for matrices (2d arrays) and especially for everything else. András > Ideally, I'd like to see a .H that was the defacto Matrix/Linear > Algebra/Conjugate transpose that for 2 or more dimensions, conjugate > transposes the last two dimensions and for 1 dimension just conjugates (if > necessary). And then .T can stay the Array/Tensor transpose for general axis > manipulation. I'd be okay with .T raising an error/warning on 1D arrays if .H > did not. I commonly write things like u.conj().T@v even if I know both u and > v are 1D just so it looks more like an inner product. > > -Cameron > > On Mon, Jun 24, 2019 at 6:43 PM Ilhan Polat <ilhanpo...@gmail.com> wrote: >> >> I think enumerating the cases along the way makes it a bit more tangible for >> the discussion >> >> >> import numpy as np >> z = 1+1j >> z.conjugate() # 1-1j >> >> zz = np.array(z) >> zz # array(1+1j) >> zz.T # array(1+1j) # OK expected. >> zz.conj() # 1-1j ?? what happened; no arrays? >> zz.conjugate() # 1-1j ?? same >> >> zz1d = np.array([z]*3) >> zz1d.T # no change so this is not the regular 2D array >> zz1d.conj() # array([1.-1.j, 1.-1.j, 1.-1.j]) >> zz1d.conj().T # array([1.-1.j, 1.-1.j, 1.-1.j]) >> zz1d.T.conj() # array([1.-1.j, 1.-1.j, 1.-1.j]) >> zz1d[:, None].conj() # 2D column vector - no surprises if [:, None] is known >> >> zz2d = zz1d[:, None] # 2D column vector - no surprises if [:, None] is known >> zz2d.conj() # 2D col vec conjugated >> zz2d.conj().T # 2D col vec conjugated transposed >> >> zz3d = np.arange(24.).reshape(2,3,4).view(complex) >> zz3d.conj() # no surprises, conjugated >> zz3d.conj().T # ?? Why not the last two dims swapped like other stacked ops >> >> # For scalar arrays conjugation strips the number >> # For 1D arrays transpose is a no-op but conjugation works >> # For 2D arrays conjugate it is the matlab's elementwise conjugation op .' >> # and transpose is acting like expected >> # For 3D arrays conjugate it is the matlab's elementwise conjugation op .' >> # but transpose is the reversing all dims just like matlab's permute() >> # with static dimorder. >> >> and so on. Maybe we can try to identify all the use cases and the quirks >> before we can make design the solution. Because these are a bit more >> involved and I don't even know if this is exhaustive. >> >> >> On Mon, Jun 24, 2019 at 8:21 PM Marten van Kerkwijk >> <m.h.vankerkw...@gmail.com> wrote: >>> >>> Hi Stephan, >>> >>> Yes, the complex conjugate dtype would make things a lot faster, but I >>> don't quite see why we would wait for that with introducing the `.H` >>> property. >>> >>> I do agree that `.H` is the correct name, giving most immediate clarity >>> (i.e., people who know what conjugate transpose is, will recognize it, >>> while likely having to look up `.CT`, while people who do not know will >>> have to look up regardless). But at the same time agree that the docstring >>> and other documentation should start with "Conjugate tranpose" - good to >>> try to avoid using names of people where you have to be in the "in crowd" >>> to know what it means. >>> >>> The above said, if we were going with the initial suggestion of `.MT` for >>> matrix transpose, then I'd prefer `.CT` over `.HT` as its conjugate version. >>> >>> But it seems there is little interest in that suggestion, although sadly a >>> clear path forward has not yet emerged either. >>> >>> All the best, >>> >>> Marten >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
