I was saying we shouldn't change the default transpose operation to be conjugate transpose. We don't currently have a conjugate transpose so it isn't an issue. I think having a conjugate transpose is a great idea, I just don't think it should be the default.
On Tue, Jun 25, 2019 at 12:12 PM Ilhan Polat <ilhanpo...@gmail.com> wrote: > I think we would have seen a lot of evidence in the last four decades if > this was that problematic. > > You are the second person to memtion these bugs. Care to show me some > examples of these bugs? > > Maybe I am missing the point here. I haven't seen any bugs because > somebody thought they are just transposing. > > Using transpose to reshape an array is a different story. That we can > discuss. > > On Tue, Jun 25, 2019, 16:10 Todd <toddr...@gmail.com> wrote: > >> That is how it is in your field, but not mine. For us we only use the >> conventional transpose, even for complex numbers. And I routinely see bugs >> in MATLAB because of its choice of defaults, and there are probably many >> more that don't get caught because they happen silently. >> >> I think the principle of least surprise should apply here. For people >> who need the conjugate transform the know to make sure they use the right >> operation. But a lot of people aren't even aware that there conjugate >> transpose exists, they are just going to copy what they see in the examples >> without realizing it does the completely wrong thing in certain cases. >> They wouldn't bother to check because they don't even know there is a >> second transpose operation they need to look out for. So it would hurt a >> lot of people without helping anyone. >> >> On Tue, Jun 25, 2019, 07:03 Ilhan Polat <ilhanpo...@gmail.com> wrote: >> >>> 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 >>> >> _______________________________________________ >> 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
