On Tue, Jun 25, 2019 at 1:03 PM Ilhan Polat <ilhanpo...@gmail.com> wrote: > > I have to disagree, I hardly ever saw such bugs <snip>
I know the exact behaviour of MATLAB isn't very relevant for this discussion, but anyway the reason I think this is a problem in MATLAB is that there are a bunch of confused questions on Stack Overflow due to this behaviour. Just from the first page this[1] query I could find examples [2-8] (quite a few are about porting MATLAB to numpy or vice versa). > <snip> 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 probably misunderstood your point here, Ilhan, because it sounds to me that you're arguing that conjugation should not come without a transpose. This is different from saying that transpose should not come without conjugation (although I'd object to both). And `.'` is exactly _not_ an elementwise operation in MATLAB: it's the transpose, despite the seemingly element-wise syntax. `arr.'` will _not_ conjugate your array, `arr'` will (while both will transpose). Finally, I don't think "MATLAB does it" is a very good argument anyway; my subjective impression is that several of the issues with np.matrix are due to behaviour that resembles that of MATLAB. But MATLAB is very much built for matrices, and there are no 1d arrays, so they don't end up with some of the pitfalls that numpy does. > > 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. > Coming back to numpy, I disagree with your statement. I'd say "just transposing a complex _matrix_ is way more special and rare than its ubiquitous regular usage", which is true. Admittedly I have a patchy math background, but to me it seems that the "conjugation and transpose go hand in hand" claim is mostly valid for linear algebra, i.e. actual matrices and vectors. However numpy arrays are much more general, and I very often want to reverse the shape of a complex non-matrix 2d array (i.e. transpose it) for purposes of broadcasting or vectorized matrix operations, and not want to conjugate it in the process. Do you at least agree that the feature of conjugate+transpose as default mostly makes sense for linear algebra, or am I missing other typical (and general numerical programming) use cases? András [1]: https://stackoverflow.com/search?q=%5Bmatlab%5D+conjugate+transpose+is%3Aa&mixed=1 [2]: https://stackoverflow.com/a/45272576 [3]: https://stackoverflow.com/a/54179564 [4]: https://stackoverflow.com/a/42320906 [5]: https://stackoverflow.com/a/23510668 [6]: https://stackoverflow.com/a/11416502 [7]: https://stackoverflow.com/a/49057640 [8]: https://stackoverflow.com/a/54309764 > 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
