I have to disagree, I hardly ever saw such bugs and moreover <Zbar, Z> is not compatible if you don't also transpose it but expected in almost all contexts of matrices, vectors and scalars. Elementwise conjugation is well inline with other elementwise operations starting with a dot in matlab hence still consistent.
I would still expect an conjugation+transposition to be the default since just transposing a complex array is way more special and rare than its ubiquitous regular usage. ilhan On Tue, Jun 25, 2019 at 10:57 AM Andras Deak <deak.and...@gmail.com> wrote: > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
