'ᵀ as syntax for transpose

[dnadlinger]

PR #38062 introduces 'ᵀ into Base.

We have had a' == adjoint(a) for a long time, so it is natural to "read" a' as aᴴ, a†, a*, or whatever your preferred math notation for the Hermitian conjugate/adjoint might be. Also, aᵀ pretty unambiguously means transpose(a).

Thus, it would be natural to assume that a'ᵀ would be equivalent to a†ᵀ, that is, transpose(adjoint(a)), or (for complex matrices) the element-wise complex conjugate.

However, that is not the case in the release candidate: a'ᵀ is defined as transpose(a)!

This strikes me as highly misleading – given how naturally Julia syntax maps to common math notation in most cases, I would have bet quite a bit on the interpretation as the transposed adjoint. This is one of those cases where one interpretation seems so natural to me that I wouldn't even have considered that somebody else could view it differently.

Perhaps this quite significantly depends on the types of mathematics one is in regular contact with? My educational background is maths/physics at ETH Zurich, and I work in quantum computing research these days. This is a context in which a'ᵀ (i.e. a†ᵀ, i.e. a*ᵀ, i.e. aᴴᵀ) actually makes sense and is reasonably common – in fact, A̅ := A†ᵀ is probably the most natural way of defining complex conjugation in many category-theory approaches to quantum mechanics –, so I can believe that this interpretation might be less immediate to people in other areas.

Still, I think it is clear that the design rationale provided in #38062, where @simeonschaub writes "I feel like transpose is really the only sensible meaning of 'ᵀ," hasn't been sufficiently examined. Since we are at rc3 already, it seems the way to go would be to pull this from 1.6 and reopen the discussion on a transposition operator for 1.7.

From my point of view, this is ambiguous enough to be a net design negative for the language as a whole – but certainly for the budding Julia quantum ecosystem, where the new operator would actively cause confusion.

[andyferris]

Hmm - I can see how it "looks" like nested adjoint then transpose, but I believe the intention was to (generically) be able to create "modified versions of '", as in "an operator like ' but just transpose". If we had a ᵀ operator by itself then your argument would of course be convincing, but we don't for exactly the same reason that x² is a variable and not x ^ 2.

but certainly for the budding Julia quantum ecosystem, where the new operator would have to be actively avoided for the sake of clarity.

Sorry, I don't see how this follows. Just like .' was used for years even though it "looked like broadcasted adjoint", the whole ecosystem knew what the built-in linear algebra functionality was, and we used it perfectly fine for quantum mechanics/quantum info/tensor networks work back then. It's simply a matter of everyone getting used to it. In fact, I highly recommend following conventions laid out in Base and the stdlibs like LinearAlgebra even when they aren't perfect because it makes for a more cohesive ecosystem.

[dnadlinger]

Sorry, I don't see how this follows. […]

I've slightly modified the wording in the original post – your argument addressed my suggestion that it would have to be avoided, but this isn't at all the point I wanted to make. No matter whether the operator ends up being used or not (in fact I fully agree that sticking to Base conventions across all application domains is a good idea!), it doesn't detract from my point that the particular convention proposed here is an unnecessarily misleading one.

Going with a new syntax that is incompatible with common math notation, particularly when it is so in an error-prone fashion (as for e.g. square complex matrices, both interpretations give results of the same size), just seems like an unforced design mistake to me. And even if it turns out that the benefits of this notation (which?) outweigh the drawbacks (increased cognitive load), surely that conclusion should be reached by a process more deliberate than "it seemed like the only sensible interpretation"?

People can still define var"'ᵀ" if it is unambiguous in their application domains, of course, but to introduce a syntax that clashes with what is part of our common language (linear algebra) to Base just seems like a bad idea.

[dnadlinger]

More to the point: You write

I can see how it "looks" like nested adjoint then transpose, but I believe the intention was […]

I've read through some of the chain of issues leading to the PR, and agree with your statement – but does it matter what the intentions were if the end result is ambiguous?

My concern is that this, which is supposed to address JuliaLang/LinearAlgebra.jl#410, leaves us in precisely the same situation with just a slightly differently coloured paint job. @ StefanKarpinski writes:

Now that .op is generally the vectorized form of op, it's very confusing that .' means transpose rather than the vectorized form of ' (adjoint, aka ctranspose).

Ironically, for the common case of complex matrices, even the "obvious" interpretation is the same for both JuliaLang/LinearAlgebra.jl#410 and this – both .' and 'ᵀ "should" be element-wise conjugation!

[simeonschaub]

Still, I think it is clear that the design rationale provided in #38062, where @simeonschaub writes "I feel like transpose is really the only sensible meaning of 'ᵀ," hasn't been sufficiently examined.

To put this in context: There had been a lot of discussion about this already and #37247 had just been merged, with the main goal being to support 'ᵀ in particular.

My concern is that this, which is supposed to address JuliaLang/LinearAlgebra.jl#410, leaves us in precisely the same situation with just a slightly differently coloured paint job. @ StefanKarpinski writes:

Now that .op is generally the vectorized form of op, it's very confusing that .' means transpose rather than the vectorized form of ' (adjoint, aka ctranspose).

In the context of Julia, I don't really think this is the same situation. In Julia, we have broadcasting syntax, which has a clearly defined meaning as broadcasting a function over sized containers and for operators is written as .op. I am pretty sure this is what Stefan meant here, since one would then expect .' to just be the broadcasting version of '.

OTOH, we support unicode suffixes for any non-syntactic operator. 'ᵀ is not at all special at a parser level, you can just as well define a +ᵀ b, !ᵟa or a'₁₂₃⁵⁶⁷ꜝ. Right now we don't export any other operator like that from Base, but the way they are generally used in packages is that e.g. +₁ is another "kind" of plus, so an operation that is similar to +, but does something a bit different, so it can't just overload Base.:+. Like @andyferris explained, this also applies, at least in my mind to ', so 'ᵀ is another kind of adjoint (or a kind of involutive antiautomorphisms if you want to be really technical), which I would definitely consider to apply to the transpose.

What IMHO further warrants this way of thinking is that ' really is not what's actually used as notation in mathematics, so it doesn't necessarily have to be the conjugate transpose, but since that's typically the most useful kind of adjoint-like operation, it's a reasonable default. I almost like to think of ' as the short form of something like '† or '* (not actually valid syntax, since Unicode does not have superscript versions of those yet), so 'ᵀ is very much natural for the transpose.

Either way, I understand that this is the kind of syntax people tend to have very strong opinions about and my opinion is just one among many, but I wanted to explain my thinking a bit better. Re-reading the old discussions, 'ᵀ still seems like pretty much the only sane option to me. The only alternative that came up was (a)ᵀ, which I personally am not a big fan of just because it looks too verbose to me and which would also be slightly breaking since there are a handful of packages that are using ᵀ as an identifier. There definitely was quite a bit of consensus around this, so I am kind of surprised this is now so controversial.

(P.S.: Sorry for the wall of text. I unfortunately can't join the next triage call, so I wanted to explain my thinking a little.)

[JeffBezanson]

Triage still doesn't like this syntax and most of us don't want to reinstate it.

[fingolfin]

But the change to "allow unicode modifiers after ' " introduced in PR #37247 is still in place. Are the further uses for this anyone has in mind?

[saolof]

Hmm - I can see how it "looks" like nested adjoint then transpose, but I believe the intention was to (generically) be able to create "modified versions of '", as in "an operator like ' but just transpose". If we had a ᵀ operator by itself then your argument would of course be convincing, but we don't for exactly the same reason that x² is a variable and not x ^ 2.

but certainly for the budding Julia quantum ecosystem, where the new operator would have to be actively avoided for the sake of clarity.

Sorry, I don't see how this follows. Just like .' was used for years even though it "looked like broadcasted adjoint", the whole ecosystem knew what the built-in linear algebra functionality was, and we used it perfectly fine for quantum mechanics/quantum info/tensor networks work back then. It's simply a matter of everyone getting used to it. In fact, I highly recommend following conventions laid out in Base and the stdlibs like LinearAlgebra even when they aren't perfect because it makes for a more cohesive ecosystem.

Honest question: what did .' actually do?

[andyferris]

Transpose, like MATLAB.

[kauesena]

I got a bit lost in the issues relating to this. Was the idea of a postfix notation for transpose totally discarded?