Circuit diagrams for unitary quantum kernels in LaTeX

[freifrauvonbleifrei]

Add LaTeX circuit diagrams to the cudaq draw() function.

Description

this PR addresses #1638

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

CLA Assistant Lite bot All Contributors have signed the CLA.

[freifrauvonbleifrei]

I have read the Contributor License Agreement and I hereby accept the Terms.

[freifrauvonbleifrei]

I am currently building the latex reference output for testing, to match this string output:

cuda-quantum/unittests/integration/draw_tester.cpp

Lines 66 to 86 in 1c76ab2

	╭───╮ ╭───╮╭───────────╮ ╭───────╮»
	q0 : ┤ h ├──●────●────●──┤ y ├┤ r1(3.142) ├──────╳─────╳──╳─────╳──●─┤> ├»
	├───┤╭─┴─╮ │ ╭─┴─╮╰─┬─╯╰──┬─────┬──╯ │ │ │ │ │ │ │»
	q1 : ┤ h ├┤ x ├──●──┤ y ├──●─────┤ tdg ├─────────┼──╳──╳──┼──╳──╳──╳─┤● ├»
	├───┤╰───╯╭─┴─╮╰─┬─╯ │ ╰┬───┬╯ ╭───╮ │ │ │ │ │ │ │ swap │»
	q2 : ┤ h ├─────┤ y ├──●────●──────┤ z ├────┤ s ├─╳──╳─────╳──╳──┼──╳─│ │»
	├───┤ ╰───╯ ╰───╯ ╰───╯ │ │ │ │»
	q3 : ┤ h ├──────────────────────────────────────────────────────●──●─┤> ├»
	╰───╯ ╰───────╯»
	################################################################################
	╭───────╮╭───────────╮ ╭─────╮ ╭────────────╮
	┤> ├┤ rx(2.718) ├────┤ sdg ├───┤ rx(-2.718) ├
	│ │├───────────┤ ╰──┬──╯ ├────────────┤
	┤● ├┤ ry(3.142) ├───────●──────┤ ry(-3.142) ├
	│ swap │├───────────┴╮╭───────────╮╰────────────╯
	┤● ├┤ rz(-3.142) ├┤ rz(3.142) ├──────────────
	│ │╰────────────╯╰───────────╯
	┤> ├─────────────────────────────────────────
	╰───────╯

This is the current draft:

\documentclass{minimal}
\usepackage{quantikz}
\begin{document}
\begin{quantikz}
  \lstick{$q_0$} & \gate{H} & \ctrl{1} & \ctrl{2} & \ctrl{1} & \gate{Y}  & \gate{R_1(3.142)} & \qw     & \swap{2} & \qw      & \swap{1} & \swap{2} & \qw      & \swap{1} & \ctrl{2} & \swap{3} & \swap{3} & \gate{R_x(2.718)} & \gate{S^\dag}     & \gate{R_x(-2.718)} & \qw \\
  \lstick{$q_1$} & \gate{H} & \gate{X} & \ctrl{1} & \gate{Y} & \ctrl{-1} & \gate{T^\dag}     & \qw     & \qw      & \swap{1} & \targX{} & \qw      & \swap{1} & \targX{} & \targX{} & \ctrl{2} & \ctrl{2} & \gate{R_y(3.142)} & \ctrl{-1}         & \gate{R_y(-3.142)} & \qw \\
  \lstick{$q_2$} & \gate{H} & \qw      & \gate{Y} & \ctrl{-1}& \ctrl{-2} & \gate{Z}          & \gate{S}& \targX{} & \targX{} & \qw      & \targX{} & \targX{} & \qw      & \targX{} & \qw      & \ctrl{-2}& \gate{R_z(-3.142)}& \gate{R_z(3.142)} & \qw                & \qw \\
  \lstick{$q_3$} & \gate{H} & \qw      & \qw      & \qw      & \qw       & \qw               & \qw     & \qw      & \qw      & \qw      & \qw      & \qw      & \ctrl{-3}& \ctrl{-2}& \targX{} & \targX{} & \qw               & \qw               & \qw                & \qw \\
\end{quantikz}
\end{document}

which produces
when run with latex and dvisvgm.

I think that .svg output should be the easiest to integrate with jupyter notebooks.

My svg viewer shows weird triangles for the numerical dots (they aren't there when I run dvisvgm --no-fonts, but then all semantics is lost, too). I would just trust that these display issues will be fixed somewhere along the toolchain, and accept them for now 🤷

@bettinaheim @amccaskey @boschmitt does this look somewhat like the thing you'd like?

[freifrauvonbleifrei]

I think this PR fulfills the requirements stated in issue #1638.

However, I would like to do some more notebook integration.
This would mean

• having a Python function that invokes subprocesses to produce the .dvi and .svg intermediate files, and returns the contents of the .svg as string. (Questions: Where does it belong in the python module? What happens in case of failure, e.g. if latex or dvisvgm are not installed, or files are not writable?)
• wrapping this in a _repr_svg_ function that can be understood by IPython . But here is the tricky part: which class should this function belong to? To obtain the trace, both the kernel and its arguments are required.

Opinions are highly appreciated!

[freifrauvonbleifrei]

The latest commit lets you display the svg in a jupyter notebook. Here, for instance, I added displaySVG to the quantum Fourier transform tutorial:

I am not entirely happy about the Python import structure though, but cannot think of a more elegant way to do it right now. Feedback is appreciated!

[freifrauvonbleifrei]

And I added a _repr_svg_ for PyKernelDecorator, which will output the svg if the kernel needs no parameters.
Here in the quantum_bits.ipynb tutorial:

[boschmitt]

Hi @freifrauvonbleifrei, thanks for all the work put into this.

I noticed that you are using C++20 concepts in the code. We also use it, however, you need to provide an alternative so that the code can also compile with C++17. For example:

cuda-quantum/runtime/cudaq/algorithms/sample.h

Lines 242 to 249 in b522e18

	#if CUDAQ_USE_STD20
	template <typename QuantumKernel, typename... Args>
	requires SampleCallValid<QuantumKernel, Args...>
	#else
	template <typename QuantumKernel, typename... Args,
	typename = std::enable_if_t<
	std::is_invocable_r_v<void, QuantumKernel, Args...>>>
	#endif

[freifrauvonbleifrei]

Hi @boschmitt , thank you for having a look. I was not aware that C++17 compatibility would be required, and it is especially surprising to me that other places in the code use concepts unguarded:

cuda-quantum/include/cudaq/Optimizer/Builder/Factory.h

Line 29 in 6c736fa

requires std::integral<T>

How are these other parts ensured to be compiled with C++20?

I can add some guards for sure, but I would like to make sure this is what is needed in the project, as readability would really suffer.

[boschmitt]

I was not aware that C++17 compatibility would be required, and it is especially surprising to me that other places in the code use concepts unguarded:

cuda-quantum/include/cudaq/Optimizer/Builder/Factory.h

Line 29 in 6c736fa

requires std::integral<T>

How are these other parts ensured to be compiled with C++20?

I was not sufficiently precise in my observation. The thing is: not all parts of the codebase have the same requirements regarding C++17 support. We need C++17 support on the public headers, i.e., the headers users would import (directly or indirectly) to develop their quantum applications. (In other words, to build the project, one needs a C++20 capable compiler. However, to use it, you only need C++17.)

The code you showed is not part of the public API and is not installed (distributed with CUDAQ). Thus, there is no need to comply with the C++17 requirement.

[bettinaheim]

Nice! Overall this looks very nice.
Let's follow up in a separate PR for the C++ 17 support in the public headers, so that we can stick to the Unitary Hack time lines.

[bettinaheim]

/ok to test

Command Bot: Processing...

[bettinaheim]

/ok to test

Command Bot: Processing...

[boschmitt]

/ok to test

Command Bot: Processing...

[github-actions]

CUDA Quantum Docs Bot: A preview of the documentation can be found here.