Non-destructive measurements

[eddieschoute]

Is your feature request related to a problem? Please describe.
It is common to use non-destructive measurements in fault-tolerant quantum computing. Depicting a sequence of these measurements using yquant is currently not obvious because a measurement only has one output: classical or quantum.

Describe the solution you'd like
A non-destructive measurement should not act only on one register but have two outputs: One classical and one quantum. The classical output could just be a (bit-)label that is used later in the circuit as classical control, which could have it's own notation so as to not draw explicit classical wires.

Describe alternatives you've considered

• I considered using a dmeter with qubit output but it's not easy to describe the classical output.
• I considered a box with $I + (-1)^b P$ for measuring $P$, but it's wide and not as natural.

Additional context
One depiction of such circuits can be found in my paper "Edge-disjoint paths for Surface Code Compilation" (sorry for the self-plug). Even simple-circuits will have many classical bits floating around and need a non-obtrusive way to represent them. See Figure 18, for example, as well as Figure 8 for a more complex one.

[projekter]

I see. This consists of two parts. I just write down my thoughts here, though implementation will have to wait a bit - my thesis has to be finished first...

• Output for the classical bit. This is fairly easy; basically, all we'd need for this is to change the dmeter or measure gate shape such that it allows to draw the upwards (or downwards; or left/right if vertical) classical wire plus a defined position where to put the info text. This is a very isolated change, as it affects these particular gates only.
• Input from a non-wire. This is not a change related to a specific gate, as all gates should be able to have this possibility. While one option would be to just add a configuration and leave it up to each gate to properly draw the lines, I don't like this so much, as it puts the control wire in this case on a special footing and creates a gate dependency - if the gate doesn't implement it, it is just silently ignored. It would be better to allow for a control "from nothing".
  • One way: create a new control type (currently there are positive and negative, now we'd need "none"), and the user then has to put this invisible control dot on the preceding or succeeding register. As already now, control knobs can have labels, this is also possible. The invisible control could take some vertical space, so that the control line doesn't extend to the wire.
    I don't like this solution, as it forces the user to put a control at some register based on a visual position, although logically speaking, there's nothing there. Plus, if the register has a larger separation due to high gates, the line will be longer, which doesn't make sense. Plus, if you want input in the topmost or bottom-most register, this is also bad.
  • Second way: Some kind of separate syntax, e.g., gate register < {text at the input};, which could be combined with | and ~ (but how would you then draw it if you have an "ordinary" plus such an "injected" control?). But we need to consider the possibilities of injecting from below and from above. So the better symbols would be ^ (from below). And what for "from above" - should we use _, as it is in some way the "opposite", although visually it is not really intuitive? There are lots of intuitive Unicode symbols, but it should be possible to type them easily and ASCII would be easiest for TeX support among all engines. At the beginning, I wrote <, which, together with > would be good options in vertical layout. But horizontal is far more common, and the circuit symbols should not change depending on the layout. Finally, how to denote the text - as I did it above using a TeX group or better using quotation marks as the TikZ quotes library does (perhaps even importing the full quotes syntax with options).
• Well, now you could also validly say that there's not really a difference between an outgoing or an incoming classical control. Maybe the styling of the line would be slightly different (arrowhead), but this is something that the gate style could easily influence; so no need to change gate shapes. Just use one consistent syntax for everything. This would probably be preferrable. But it leads to the problem that ^ was "from below" before (or > was "from the left"). Should this meaning stay the same, or should we instead now say, the flow of information is reversed, so ^ means "to the top" and > to the right?

[eddieschoute]

One note on the last point: Gates can only consume bits, but there are also situations where a measurement may depend on a bit in addition to producing a bit. For example, the auto-corrected magic state injection circuit can have a conditional basis change in the measurement apparatus that follows from an earlier, conditional S gate. I am not aware of standard notation for this.
Otherwise, I simply do not draw classical wires and have the bit values be represented by variables that float above the gates themselves. One could also already write $U^b$ to represent a gate that is identity when the bit value $b=0$.

[projekter]

Just to make sure that you are aware of the possibility to always just draw what you want manually: For example, for a dmeter, you could do something like

\begin{yquant}
   qubit q[5];
   h q;
   [name=meas]
   dmeter q[2];
   \draw[double] (meas.north) ++(-.1, 0) -- ++(0, .2) node[anchor=west, font=\footnotesize, inner sep=1pt] {$A$};
   settype {qubit} q[2];
   h q;
\end{yquant}

Of course, the manual drawing will not be recognized and therefore won't be part of the register height.
And as it must be done after the gate is drawn (for the shape to be known), it will be drawn over the gate - to I took care to place it a bit to the left, where the line is horizontal. The measure shape won't have this issue.
Of course, you can quite easily put this into a macro, depending on how sophisticated it should be. Here's a simple version:

\documentclass[tikz]{standalone}

\usepackage[compat=newest]{yquant}

\makeatletter
\tikzset{
   inline output/.style={anchor=west, font=\footnotesize},
   inline bottom output/.style={},
   inline top output/.style={}
}
\def\dmeter{%
   \@ifnextchar_\dmeter@i{\dmeter@i_{}}%
}
\def\dmeter@i_#1{%
   \@ifnextchar^{\dmeter@ii_{#1}}{\dmeter@ii_{#1}^{}}%
}
\def\dmeter@ii_#1^#2#3;{%
   \yquant [name=meas] dmeter #3;
   \ifstrempty{#1}\relax{%
      \draw[double] (meas.south) ++(-.1, 0) -- ++(0, -.2) node[inline output, inline bottom output] {#1};
   }
   \ifstrempty{#2}\relax{%
      \draw[double] (meas.north) ++(-.1, 0) -- ++(0, .2) node[inline output, inline top output] {#2};
   }
   \yquant settype {qubit} #3;
}

\begin{document}
   \begin{tikzpicture}
      \begin{yquant}
         qubit q[5];
         h q;
         \dmeter_{bottom}^{top} q[2];
         h q;
      \end{yquant}
   \end{tikzpicture}
\end{document}

(Note that it doesn't matter that the shape is always called meas. You can use the macro as often as you want, the next one will just overwrite the previous one.

[eddieschoute]

I reduced the vertical length of the lines to .1. I think that looks better. Now the text just has to be placed reasonably. Can't we place the text relative to the second node of the classical output wire?

[projekter]

What do you mean with "second node of the classical output wire"? The classical wire is just the line that is drawn, and at the end of this line, the node is placed. Of course, you can do any placement that TikZ offers (which is virtually anything you can think of).

[eddieschoute]

You used node[inline output, inline top output] to shift the text node to the right, but I'd rather have it vertically above the double line (or below). So if I replace the node with

		   \draw[double] (meas.north) ++(-.1, 0) -- ++(0, .1) node[yshift=0.1cm] {#2};

then that looks fairly good to me if the node's text is very short (say a bit label $b$).

[projekter]

I would simply change the node anchor from west to south (in any case, because if you don't specify an anchor, it'll be center - which means that the vertical position will change depending on the depth of you text. So better so anchor at the bottom. And then you can use the yshift, if you're still not satisfied (or adjust inner ysep). Or you can shift the path position before creating the node, e.g., by inserting another ++(0, .1) (or something similar) before right before the node - which has the advantage (or disadvantange, depending on how you see it) that the units are not absolut, but relative, so this distance will scale if you scale the whole picture. There are many possibilities - if the output looks good (and continues to do so for other reasonable texts and settings), just choose any to your liking.

[eddieschoute]

To circle back on this, we decided to hand-make circuits using vector graphics in our recent paper. In particular, the graphical language in eq. (1) was the reason for me posting this issue:

I would say yquant isn't too far of from producing comparable circuits and it would've saved a lot of fiddling with inkscape. However, the highlighting in some equations and other more custom design elements may have been hard to replicate.

[projekter]

It's always the question of how much of a "specialist" yquant should be. It should be easy to produce "standard" quantum circuits, but of course, given that this is an evolving topic, it is hard to define what standard is beyond the stuff in Nielsen & Chuang.
It is rather easy to replicate many things using the fact that yquant is based on TikZ. Maybe someone has to learn TikZ for this, but this is unavoidable, and it is really so worth the effort. Given that TikZ's software manually is literally the best one I've ever read, learning the basics of TikZ is rather enjoyable.
The first two pictures are very easy to reproduce in native yquant, just using slash, box, a fill and rounded corners. The third is basically just a measure gate and a path with a node below, and for the last, you simply name both boxes and draw the lines with relative coordinates. If you know TikZ, this is maybe a minute or two of effort and very straightforward.
Compared to the issues that we discussed, when I implement something like this as a native feature in yquant (and note that what you show in the fourth circuit was not proposed before, I think), it really has to be foolproof and work in any reasonable situation, which is neither fast nor straightforward. Since reasonable covers very much - I would stop at making the lines wider than the boxes are, which will break the yquant layout. But apart from this, we'd have to think of every possible situation that could occur, taking into account that what we are adding are primarily visual things that are supposed to have a meaning, but researchers like to define new meanings, making senseless stuff meaningful. In the latest release, I implemented the corner gates (fan in/fan out). Given how simple they look, they were surprisingly hard to get right in all situations (and right means exactly perfect by the pixel).
And then, it has to be integrated in yquant's language - it is not too helpful if we support some fancy stuff, but users have to use these special commands in combination with this gimmick - then it doesn't fit the purpose of yquant. Basically, then, you could have just done it using the TikZ layer.

Don't take me wrong, I'm absolutely not opposing the idea of integrating non-destructive measurements in yquant. I think it could really be helpful. But what I need for this is:

• a complete description of how things should look like, thinking of all possible situations (all possible incoming/outgoing wire types, positive and negative controls, multi-qubit gates, multiple single- and/or multi-qubit targets in the same command, the possible positioning in a circuit: first register; first register of all targeted ones; start/middle/end of a (multi-register) target; last register of all targeted ones; last register), deferred or direct measurement. Looking at your last picture, even the so-far unconsidered case of "connected" gates with stuff in between, and what this stuff could be. These are lots of situations. Maybe, sometimes the answer is: the gate should not support this and that situation because of... - and this is fine. But if it is in principle viable, it must be considered, and the solution must be a good one.
• since I'm not working in this field, some references that show that the notation is at least a prominent one among multiple ones in use. It would not be great if some time later, preference actually shifts to a different notation. Of course, integration in yquant can also help promoting it as "the" notation (though many more authors [still ;)] use qcircuit or quantikz - or Inkscape if their stuff is too fancy). This is a position that should not be abused, so the way of depicting it should really be a very expressive one.
• some proposal on how it could look like to write down a circuit such as this in yquant. It should be easily understandable. It would be beneficial if it feels like a native feature, but if need be, it could also be a macro. For example, something that I really want to add at some point are more sophisticated native highlighting capabilities. But this won't be possible using "just" yquant's language, as highlighting can often break elements that logically belong together for yquant - only parts of a gate for example. So it will have to be a macro. But it must be better than what is already possible right now by naming the nodes and fitting the rectangle or drawing any custom form in TikZ, which is also rather easy.