[Numpy-discussion] Syntax Improvement for Array Transpose

Ilhan Polat ilhanpolat at gmail.com
Tue Jun 25 07:03:11 EDT 2019


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.andris at gmail.com> wrote:

> On Tue, Jun 25, 2019 at 4:29 AM Cameron Blocker
> <cameronjblocker at 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 at 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 <ilhanpolat at 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.vankerkwijk at 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 at python.org
> >>> https://mail.python.org/mailman/listinfo/numpy-discussion
> >>
> >> _______________________________________________
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion at python.org
> >> https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190625/84e8f35d/attachment-0001.html>


More information about the NumPy-Discussion mailing list