CSWAP raises warning

[tigerjack]

\documentclass[tikz]{standalone}
\usepackage[compat=0.6]{yquant}
\begin{document}
\begin{tikzpicture}
  \begin{yquant}
    qubit {} a[3];
    swap (a[0], a[1]) | a[2];
  \end{yquant}
\end{tikzpicture}
\end{document}

The previous circuit, although producing the correct result, raises the following warning

Package yquant.sty Warning: Ambiguous operation: multiple discontiguous multi-register operations in combination with controls make it hard to visually determine on which registers the gates act on. on input line 7.

I'm using lualatex, but the warning is also raised with xelatex and pdflatex. Tex version is TeX 3.141592653

[tigerjack]

The warning goes away if I use an additional qubit, like this

\documentclass[tikz]{standalone}
\usepackage[compat=0.6]{yquant}
\begin{document}
\begin{tikzpicture}
  \begin{yquant}
    qubit {} c[1];
    qubit {} a[2];
    swap a | c; % I use a separate qubit as control
  \end{yquant}
\end{tikzpicture}
\end{document}

[projekter]

First of all, it is just a warning. Therefore, you may always ignore those possibly without any issues.
Second, the warning does not go away, but it just does not apply to the second situation. In the first situation, you place a multi-qubit SWAP gate on the qubits a[0] and a[1] with some control. In the second situation, you place two single-qubit SWAP gates (yes, this does not make any semantic sense, but it cannot be distinguished visually due to how the gate looks like). So semantically, your second example is something completely different, which you can easily see if you replace the SWAP operation by, e.g., a box gate.
Third, the meaning of the warning is that if a multi-qubit gate spreads among various registers, it just grows in size. However, if a gate acts on multiple discontiguous registers (say, just 1 and 3), it cannot do this (how would you then notice that it does not act on 2). Therefore, it is split into two parts which are connected by a vertical wavy line. Now, if you have controls, the control line must extend from the topmost to the bottommost involved register. Obviously, this leads to overlapping lines and will make the whole circuit not only visually displeasing, but hard to grasp.
You might now say that this has nothing to do with the current situation, as a[0] and a[1] are adjacent. True, but the SWAP gate is special: The shape of the SWAP gate is a cross. Now, clearly this cross does not scale vertically into a giant distorted cross when it's acting on multiple gates. Instead, even adjacent registers are always treated as discontiguous. Therefore, the situation that I described above always applies to SWAP. And SWAP also restyles the line between such now-discontiguous registers: It becomes a straight instead of a wavy line, as this is how the gate usually looks like.
Due to these specialties, the warning above actually does not make a lot of sense. But I'll have to think of how to be effective here - the warning should only occur if multiple SWAPs are written with a control, as in swap (a), (b) | c; - now there's absolutely no way to see what is swapped, although it is in priciple a valid operation and indeed perfectly fine without the control. But I won't be doing this on my holiday.

[projekter]

Oh, and of course you can just turn off the warning globally, for all SWAPS, or locally by setting /yquant/operator/multi warning to false at the appropriate places.

[tigerjack]

I've got a better handle on where this behavior is coming from now, and I appreciate the explanation. I just wanted to mention a couple of things:

1. About those box gates divided by the squiggly line – any particular reason the control line needs to go all the way across the bottom register? The squiggly line itself already implies a connection between the different parts, so adding that extra straight line feels a bit unnecessary.
2. What if swap gates are treated like 'zz' gates? It only requires changing two
   dot symbols to a cross. I'm not sure how feasible that is, but it might help address the problem.

By the way, I don't want to mess with your holiday vibes at all! If you need any assistance with testing or anything else, just give me a shout.

[projekter]

1. Yes, this is of course correct - there is no good reason why the control line should extend all the way down. It would be enough if it went to the first (or last, depending on where the control is) register that is affected by the multi-register gate. However, there are certain scenarios that have to be thought about:

   • There is not just one gate, but multiple, all controlled by the same. Then, we cannot just draw a line to the outer boundary of the closest, but it has to continue.
   • There are not just controls all above the gate, but also below. Then, we need to draw lines on both sides.

   Now, these are all somewhat unprobable scenarios. There is not really an established standard of how to even draw multi-register gates over non-adjacent registers. (Which makes sense, as hardware support...still has a lot of potential.) The squiggly line was just a choice of mine. Maybe this will also change if the community decides to, say, keep the straight line, rendering the whole discussion obsolete. The reason for my choice was that with just straight lines, it is not possible to distinguish a controlled non-contiguous multi-register gate from two controlled single- (or contiguous multi-)register gate.

   The current behavior in yquant is just the one that is easiest to implement: A control line by definition always runs from the topmost to the bottom-most register that is involved. In both scenarios that is sketched above, you could of course say: But the squiggly line basically means that this is just a single gate, and we don't draw control lines without gates. I agree, but I'll have to think a bit more possible edge cases.

2. What do you mean by "treated like zz gates"? In which scenario? From the logical side, the only difference between those two gates is that zz does not accept controls. From the drawing side, the "x" shape is drawn in a very weird and careful way to enable clipping, while the zz circles need decidedly less attention, but I don't see the differences in behavior. And while I said "swap is special", there are other gates that are special in the very same way, it is not an exclusive specialty ;). zz is special in the same way as swap, which basically means that /yquant/operator/multi as single is in effect.

3. To come back to the original warning. It is tricky. In the case that the squiggly line is in effect, it is always possible to see that a multi-register gate is acting, although it might lead to bad optics if the lines intermingle. In case the line has been replaced by a straight line (which happens for all multi as single operators), it is unclear how the gates all act together. However, there is further knowledge available about the gates which tells us that they won't ever occur in a single-register context. This is true for all multi as single gates, which are xx, zz, swap, and iswap. So in this particular case, it would make sense to suppress the warning unless there are two multi-register gates plus control in a single operation.

Please check the latest commit, which should address the warning issue.

[tigerjack]

1. I agree on this, there are several edge cases. While sketching my algorithms on paper, I often uses a puzzle pieces notation, which you can see below. I am bad at drawing, but the point on how to differentiate multi-target control qubits and multi-register gates should be clear. I don't know how difficult it is to implement it using tikz though.
   

2. I was thinking of something like this, which allows avoiding treating the swap like a general box. Note that the code doesn't work, it is just to show the idea.

\begin{yquant}
  qubit {$q_\idx$} q[4];
  % 
  [this control/.code={\unexpanded{%
      \ifcase\idx\relax%
        \pgfkeysalso{cross}%
      \or%
        \pgfkeysalso{cross}%
      \else%
        \pgfkeysalso{circle}%
      \fi%
    }}]
  zz (q[3], q[0], q[1], q[2]);

\end{yquant}

3. Thanks! The latest version removes the warning indeed.

[projekter]

1. This would certainly be possible, but not so immediate. Basically, for every possible, I'd have to create four variants: plain, with indent on top, with extrusion on bottom, and with both. Then, a corresponding trigger key would have to be set automatically by yquant. And it's still necessary to have a fallback, as some shapes are just incompatible with such a puzzle-piece notation (swap being the best example). So, yes, doable, but quite a bit of work. But it could be a nice alternative way to draw this. Perhaps I'll find some time for this some time (or if you or anybody else wants to give it a try, you're welcome).
2. So you basically want to fool yquant into displaying something different from what the code logically represents. Sure, you can do this. Have a look at the only at style, which I added in 0.7.3 (because of Styling controls individually #25). Using this, it is fairly easy. You just have to change the shape of the nodes. Usually, for zz it is yquant-circle, if you want a cross, use yquant-swap instead. Of course, you can also use a swap gate and change the style of the control node to yquant-circle and add some filling.
3. Good, so I'll close this.

[tigerjack]

Hi @projekter , thanks for your reply.

1. If you want to consider a style change for multiqubits gates, even a simpler notation would help. The puzzle proposal of mine is just an option, but you can think of others. Another alternative could be to use the small triangles. Check for example this output, made of dirty hacks

\documentclass[tikz]{standalone}
\usepackage[compat=0.7]{yquant}
\useyquantlanguage{groups}
\usetikzlibrary{shapes, shapes.misc}
\usepackage{amssymb}
\begin{document}

\newcommand\withsouth[2]{%
  \yquant [name=southgate] #2;
  \node[inner sep=0pt, yshift=-5.6pt] at (#1 -| southgate.south) {$\scriptscriptstyle\blacktriangle$};
}
\newcommand\withnorth[2]{%
  \yquant [name=northgate] #2;
  \node[inner sep=0pt, anchor=north, yshift=7pt,fill=white] at (#1 -| northgate.north) {$\scriptscriptstyle\blacktriangledown$};
}
\newcommand\withboth[2]{%
  \yquant [name=meridiangate] #2;
  \node[inner sep=0pt, yshift=-5.6pt] at (#1 -| meridiangate.south) {$\scriptscriptstyle\blacktriangle$};
  \node[inner sep=0pt, anchor=north, yshift=7pt] at (#1 -| meridiangate.north) {$\scriptscriptstyle\blacktriangledown$};
}
\begin{tikzpicture}
  \begin{yquant}
    [name=q1]  qubit x;
    qubit {} a[3];
    [name=q2]  qubit y;
    qubit {} b[3];
    [name=q3]  qubit z;
    zz (x,z, a[2], b[1]);
    hspace {-6mm} -;
    \withsouth{q1}{[fill=white]box {G} x}
    \withboth{q2}{[fill=white]box {G} y}
    \withnorth{q3}{[fill=white]box {G} z}
  \end{yquant}
  \end{tikzpicture}
\end{document}

The output is the following. It was a quick POC, but you get the idea.

Unfortunately, I do not know much about the inner working of tex to help you. I just adapted the code you provided in a previous reply

2. More or less. I was proposing to treat the swap gates differently from a generic multibox gates, but instead use for it the same implementation of the zz gate, but with a different shape. Something like what you suggested already, that is

  \begin{yquant}
    qubit  q[2];
    %   
    [operator style={only at={0}{shape=yquant-swap,radius=.75mm,draw}}]
    zz (q[1], q[0]);
  \end{yquant}

But under the hoods, avoiding therefore the problems with the other box gates.