I would love for there to be .H property. I have .conj().T in almost every math function that I write so that it will be general enough for complex numbers.
Besides being less readable, what puts me in a bind is trying to accommodate LinearOperator/LinearMap like duck type objects in place of matrix inputs, such as an object that does an FFT, but acts like a matrix and supports @. For my objects to work in my code, I have to create .conj() and .T methods which are not as simple as defining .H (the adjoint) for say an FFT. Sometimes I just define .T to be the adjoint/conjugate transpose, and .conj() to do nothing so it will work with my code and I can avoid making useless objects along the way, but then I am in a weird state where np.asarray(A).T != np.asarray(A.T). 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. 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
