Quantum Computing with Differentiable Quantum Transforms

Computation of quantum gradients is a key application of batch transforms. Consider, for example, the parameter-shift rules for computing gradients of parametrized unitaries on quantum hardware. Given a parametrized quantum circuit functionwhere

the parameter-shift rule allows us to compute the partial derivative of the expectation value by executing the same quantum function with (equidistant) shifted values [39]:Here R is the set of all (unique) pairwise differences of the eigenvalue spectrum of unitary generator G.¹ In essence, we can evaluate the gradient of \(f(\theta)\) with respect to a particular parameter value \(\theta\) by evaluating the circuit at \(2R\) points and then algebraically combining the results. This could be accomplished by a batch transform that creates a separate quantum program for each term in the sum and then combines the results according to Equation (4).

Note that for the case where \(R=1\) (corresponding to single-qubit rotation gates), the above parameter-shift rule reduces to the commonly known two-term rule [33]:This can be easily extrapolated to other types of gradient computation, such as finite-differences, or for gates that permit more complex parameter-shift rules (such as the controlled-rotation gates with four-term shift rules).

Quantum compilation is the process of decomposing a high-level specification of a quantum algorithm into a sequence of elementary operations in a format suitable for a particular quantum device. This is an extensive pipeline with numerous components: circuit synthesis, circuit optimization, transpilation, hardware-specific qubit placement and routing, gate scheduling, and optimization of low-level pulse controls.

All these tasks can be naturally viewed as quantum transforms: A circuit is fed in as input, and a modified and/or optimized circuit comes out. Compilation is implemented in this manner in many other quantum software libraries. These often consist of a pipeline of one or more passes through a set of subroutines that transform the circuit. Such subroutines typically manipulate the circuit at the level of its directed acyclic graph. There is some existing work that provides guidance on how to put together automated pipelines [27]. Software tools for compilation such as t\(|\)ket\(\rangle\) [34], staq [2], quilc [35], Qiskit [3], Cirq [8], XACC [25], QCOR [28, 29], Quipper [11], and the transforms in PennyLane, all give the user the flexibility to define pipelines based on a set of available building blocks. In particular, t\(|\)ket\(\rangle\) explicitly uses a modular transform system in its software. Both t\(|\)ket\(\rangle\) and PyQuil have support for partial or parametric compilation, respectively, which makes compilation of parametrized circuits more efficient by first tracing through execution with symbolic variables, and then specifying the numerical parameter values at runtime.

Implementing compilation using differentiable transforms allows for optimization of parametrized circuits without compromising the differentiability of the parameters. For example, consider a single transform that modifies a quantum program by finding adjacent rotations of the same type on the same qubit and combines them into a single rotation, e.g., \(RZ(\phi) RZ(\theta) = RZ(\phi + \theta)\). If both \(\phi\) and \(\theta\) are trainable parameters, then the sum of these values represents a new trainable parameter, which we call \(\lambda = \phi + \theta\). If implemented in an autodifferentiable manner where operations on parameters are traced during a forward pass, then we can compute the gradient of \(\lambda\) alone and use it to extract the gradients of \(\phi\) and \(\theta\). This can be advantageous if using, for example, the parameter-shift rule of Equation (5). With only one trainable parameter, we must evaluate the program only twice, rather than four times in the case where each gradient must be computed individually.

Many common tasks in both noise characterization and error mitigation can be framed and explored in the context of differentiable transforms. The most basic application is to use transforms to add noise; a single parametrized transform may modify a quantum program by inserting applications of a parametrized noise channel after certain types of gates to simulate the behavior of a noisy device. As transforms are composable, such noise models are highly customizable and allow for varying types and amounts of noise to be added.

However, perhaps a more interesting task is to leverage differentiable transforms to characterize noise. One can create a parametrized noise model as described above and use the results of experiments on a noisy device to learn the values of the noise parameters that most closely match the observed behavior. Thanks to the autodifferentiability of the transform parameters, this can be done using standard optimization techniques such as gradient descent.

Error mitigation methods are essential when running computations on noisy near-term quantum devices. One such method, zero-noise extrapolation (ZNE), estimates a noiseless value of a result by running a circuit for increasing values of some scale factor that adds noise and then extrapolates the results back to the zero-noise case [15, 19, 21, 37]. ZNE naturally incorporates both single and batch transforms: a number of common methods used for addition of noise, such as CNOT pair insertion and unitary folding [9], can be implemented as single transforms; we can then implement a batch transform that uses the single transform to create new programs with different amounts of noise and then compute a function of the results to obtain the mitigated value.

Single-tape transforms are the base unit of transforms. They are one-to-one processes that loop through a tape’s contents (a list of operations and a list of measurements) and queue the modified operations and measurements to the current context. The transform may accept one or more parameters that affect how the tape is modified. Convenience decorators are provided to ease the construction of tape transforms and other types of transforms. A simple example is presented in Figure 2, wherein all \(CNOT\) gates are converted to \(CZ\) and Hadamard gates by way of a textbook circuit identity.

A single tape transform can be applied to a tape directly (such as one constructed in the manner of Figure 1), and a new tape is returned. Alternatively, the same implementation can be used to create a quantum function transform (qfunc transform), which is an elevated tape transform. Quantum tapes are a lower-level data structure, and generally accessed and manipulated internally (e.g., constructed by a QNode prior to execution), rather than being user-facing. Therefore, qfunc transforms enable the same functionality at the abstraction level of functions. In fact, a tape transform can be converted to a qfunc transform simply by changing the top-level decorator from @qml.single_ tape_transform to @qml.qfunc_transform. A qfunc transform can also be applied directly to quantum functions as a decorator, with no need to consider tapes at all beyond the implementation of the transform itself. This flexibility enables us to easily compose qfunc transforms by chaining functions or by stacking decorators.

Transforms may also contain classical processing that affects the parameter values of operations on tapes. PennyLane includes a special module, pennylane.math, which enables manipulation of the parameter values (more generally, tensors) in a way that is agnostic to the underlying classical machine learning framework and thus preserves differentiability. For example, Figure 3 demonstrates a transform that modifies all qml.RX rotations to rotate by the square root of the original rotation angle. We can then write a quantum function that applies qml.RX rotations, apply the transform, and compute the gradients with respect to the input parameters in any framework (in Figure 3 PyTorch is used).

Batch transforms are one-to-many transforms that take one tape as input and return a collection of tapes as output. Furthermore, in PennyLane, they may also return a classical processing function that acts on the results of the executed quantum tapes to compute a desired quantity (this function should also be differentiable). A key use case of batch transforms is the computation of quantum gradients, which was discussed in Section 2.2.1 and is shown graphically in the left panel of Figure 4. The ability to differentiate and compose transforms ensures that we can compute nth order derivatives without any obstacles.

Batch transforms can also be used to compute the expectation value of a Hamiltonian, as depicted in the right panel of Figure 4. Letwhere \(\mathcal {P}_{n}\) is the n-qubit Pauli group, and let \(U(\theta)\) be a parametrized quantum circuit. We can compute the expectation value of \(\hat{H}\), \(\langle \hat{H} \rangle\), after applying \(U(\theta)\) as a linear combination of the expectation values of its constituent terms,

To compute \(\langle \hat{H} \rangle\) using a batch transform, we first transform the initial tape into multiple tapes, each of which measures the expectation value of an individual \(P_{i}\) (alternatively, we can partition the terms of \(\hat{H}\) into commuting sets, and compute one expectation value per set [10, 13, 14, 38, 40]). The tapes are then executed, and the results fed into a processing function that implements Equation (7). An example is shown in Figure 5 using the Hamiltonian and tape depicted in Figure 4. This particular batch transform is built-in to PennyLane as qml.transforms.hamiltonian_expand.

Batch transforms can also be applied as a decorator directly to QNodes; the outcome of executing the QNode is simply the output of the classical processing function. If both the transform and processing function preserve differentiability of all parameters, then the output of this processing function can be fed as input to other parts of a differentiable quantum program, or itself be differentiated (as will be demonstrated in Section 3.3.3).

The qml.transforms module contains two other types of transforms that do not fit the criteria above: device transforms and information transforms. Device transforms act on PennyLane devices, modify their internal workings, and return a new device with different behavior. Figure 6 presents an example, qml.transforms. insert, which adds additional gates at specified points in the circuit. This can be used to, e.g., add simulated noise at the level of the device.

Information transforms are non-composable, non-differentiable transforms that take a tape, quantum function, or QNode as input, and return a function that will compute and/or display information about that input. Key examples are qml.draw, which returns a function that outputs a text-based visual representation of the circuit, and qml.specs, which takes as input a QNode and returns a function that computes its quantum resources.

While the parameter-shift rule works for a large variety of gates in variational quantum algorithms, we occasionally chance upon unitaries that we wish to train on hardware that do not permit a parameter-shift rule. This could be for a variety of reasons; perhaps the unitary does not satisfy the form \(e^{iGx}\), or the eigenvalue spectrum of its generator is unknown.

In such cases, we typically must fall back to numerical methods of differentiation on hardware such as the method of finite-differences. Previous work exploring finite-differences in a noisy setting has shown that the optimal finite-difference step size for first-order forward difference is of the form [24]where N is the number of shots (samples) used to estimate expectation values, \(\sigma _0\) is the single-shot variance of the estimates, and \(f^{\prime \prime }(x)\) is the second derivative of the quantum function at the evaluation point. While for large N we can make the approximation \(h^*\approx N^{-0.25}\), for small N on hardware, we must manually compute the second derivative of the quantum function in order to determine a decent estimate for the gradient step size, which can further introduce error while adding a prohibitive number of additional quantum evaluations required per optimization step. Instead, we can wrap the gradient computation in a quantum transform that learns optimal parameters for the finite-difference step size in the presence of noise.

Consider a variational quantum function circuit that we would like to optimize on a noisy device using first-order forward finite-differences and \(N=1,\!000\) shots. Rather than hard-coding a constant finite-difference step size, we can include the variance of the single-shot gradient as a quantity to minimize in the cost function by using the qml. gradients.finite_diff transform.

An implementation is presented in Figure 9; the full code example, including the circuit definition, is available on our GitHub repository. Starting with \(x=0.1\) and \(h=10^{-7}\) (the default step size value of the finite_diff transform), we can now write an optimization loop that

The results of this “adaptive step size finite-difference” optimization is compared to both a naïve finite-difference optimization (using the default step size of \(h=10^{-7}\)) and the optimal finite-difference optimization (by computing Equation (8) at every step) in Figure 10. It can be seen that the naïve finite-difference optimization fails to converge to the minimum at all; a step size of \(10^{-7}\) results in a very large quantum gradient variance (as can be verified from Equation (8)). The adaptive finite difference, as well as the optimum finite difference, by contrast, are both able to converge to the minimum, with the optimum variant converging particularly quickly, as would be expected.

Nevertheless, the results show that knowing the underlying theoretical characteristics of a system (such as in the optimal case) are not required. By simply encoding the quantities we wish to minimize—the expectation value and the gradient variance—the use of differentiable quantum transforms allows us to train the model hyperparameters to minimize error during gradient descent. Such approaches may also be viable in more complex models, where optimal or error-minimizing hyperparameter values are not known in advance.

The core difference between circuit compilation in PennyLane and other quantum software libraries is that nearly all of its compilation routines are quantum transforms that preserve differentiability.³ This is accomplished by only applying mathematical operations on the parameters through which gradients can be propagated in the underlying autodifferentiation frameworks. This occasionally requires framework-specific considerations such as typecasting or addition of very small numbers to avoid undefined gradients around critical values. As the framework-specific handling of operations is done within the transforms using qml.math, a user need only pass variables with the type of the desired framework to a QNode and request that circuit be compiled; the framework can be interchanged without any modification to the quantum functions themselves.

All compilation transforms are implemented as qfunc_transforms, and as such, manipulate a circuit at the level of its tape. Transforms include rotation merging, single-qubit gate fusion, inverse cancellation, and moving single-qubit gates through control/target qubits of controlled operations. A top-level qml.compile transform is made available to the user to facilitate creation of custom compilation pipelines. The right panel of Figure 11 displays an example pipeline that consists of pushing commuting gates left through controls and targets of two-qubit gates and then fusing all sequences of adjacent single-qubit gates into a single qml.Rot (general parametrized unitary) operation. This yields the reduced-size circuit in the left panel of Figure 11. The compiled circuit remains fully differentiable with respect to the input arguments, even though they may not appear directly as the arguments in any of the gates of the compiled circuit.

At the end of the code listing of Figure 11, the method to obtain the gradients with respect to the input parameters is shown. Differentiable compilation can reduce the quantum resources required to compute gradients, as the autodifferentiation framework keeps track of the changes in variables and can produce circuits with a reduced number of parameters. A disadvantage of applying transforms in this way is that every circuit execution involves feeding the quantum function through the transform pipeline. For large circuits and multi-step pipelines that involve more mathematically complex operations such as full fusion of single-qubit gates, this could lead to significant temporal overhead. This is especially undesirable for gradient computations, as these by nature involve multiple executions of a quantum circuit.

Most of PennyLane’s circuit compilation transforms remain differentiable even after applying JIT compilation. As opposed to traditional (classical) compilation that is performed prior to runtime, JIT compiles a program dynamically at runtime. For instance, in JAX [6], this is accomplished for jax.jit using tracing: On the first execution, a “tracer” object is sent through the code, keeping track of the operations performed on it. This is then compiled into a function in an intermediate representation and can be run with real inputs. The first execution of JIT-compiled code takes substantially longer due to the time required to trace; however, subsequent executions are much faster as they are executed using the optimized version. Other frameworks have analogous functionality, such as tf.function in TensorFlow, which first constructs a computational graph using a traced object.

Here we show an explicit example using the JAX interface and jax.jit. Enabling compatibility of quantum transforms with JIT requires different considerations than ensuring differentiability with respect to arguments is preserved. In particular, conditional statements present a challenge for the tracer. For example, suppose that in the process of merging a sequence of \(RZ\) gates, a cumulative angle of 0 is obtained. If optimizing by hand, or in non-jitted code, then whether to apply that gate can be expressed using a conditional statement that checks the value of the angle. However, this leads to two branches of the code with different structure: one in which a gate is applied and one in which it is not. In JAX, one can use a special type of conditional (jax.lax.cond) that is recognized by the tracer; however, the output of both branches must have the same type and shape, and furthermore, it must be a JAX type such as an array (i.e., not a quantum gate). Thus, when jitting, one is limited to using the conditional branches to compute and return some function of a gate’s numerical parameters, and that gate runs even if the parameter is 0. PennyLane’s transforms contain separate conditional statements that first check whether a gate’s parameter is a tracer object prior to compiling. Then, jitted compilation can be done at the cost of occasionally applying a gate with a trivial parameter, and non-jitted compilation will always remove such gates. However, more sophisticated routines such as the two-qubit unitary decomposition are currently non-jittable: The structure of the circuit is computed as a function of the unitary and has four conditional branches with template circuits that depend on the computed number of CNOTs.⁴

Two-qubit decompositions notwithstanding, JIT compilation yields benefits in both the classical and quantum aspects of running an algorithm. The classical preprocessing, which involves applying the quantum transforms, becomes significantly faster after the first jitted evaluation, as it has been compiled to machine code that is then executed directly, bypassing the Python interpreter. We can then run the optimized circuit on quantum devices, which will typically have lower depth and fewer operations, without additional overhead. Furthermore, the same can be done for computation of gradients: Not only may the number of quantum evaluations be reduced as a result of compiling the circuit, but the jitted gradient, after the first execution, will run significantly faster than the original.

Consider the circuit in Figure 12 that has 20 parameters. Using jax.grad to evaluate the gradient with the parameter-shift rules leads to 41 device executions (two per parameter, plus one for the initial forward pass). Running the same circuit but compiling using the qml.transforms.single_qubit_fusion transform will merge all adjacent single-qubit gates. The compiled circuit has 15 effective parameters, as well as lower circuit depth (expanding the rotations gives an original depth of 10, and compiled depth of 8). Table 1 presents sample runtimes for computing the gradients of this circuit. Even though the number of quantum evaluations is lower, the application of the transform adds significant time overhead. However, jit can be applied to both the original and compiled gradient functions to speed up the computation substantially.

New values of the parameters can be passed to the jitted and compiled gradient function without needing to run jit again. In variational algorithms, where a circuit and its gradient are evaluated on the order of thousands of times with different parameters over the course of the optimization process, this would lead to a substantial speedup. While this is only a small example, it demonstrates that ensuring compilation transforms preserve differentiability of the input parameters can lead to benefits both when executing on a quantum device and on a simulator.

In this section, we will implement fully differentiable ZNE (i.e., the extrapolated value is itself differentiable with respect to the input circuit parameters) with unitary folding [9]. In this method, a circuit U is first applied, followed by repetitions of \(U^{\dagger }U\). Following the example of the error-mitigation library mitiq [19], the number of such folds \(n_{f}\) is computed based on a scale factor \(\lambda\) according to the expression \(n_{f} = (\lambda - 1)/2\), rounded to the nearest integer. A qfunc transform implementing this is shown in the left panel of Figure 13.

ZNE is naturally implemented as a batch transform, shown in the right panel of Figure 13. The transform creates multiple versions of the initial tape with different amounts of folding. It then returns those tapes, along with a processing function that performs the noise extrapolation on the results of executing the tapes (implemented in fit_zne).

The zne batch transform can be applied either to a quantum tape to obtain the transformed tapes and processing function, or to a QNode to directly obtain the mitigated value. In fact, once defined, a user can obtain error-mitigated results simply by adding a single line to their code: the @zne decorator. Some pseudocode for this process is demonstrated in Figure 14 (the full example included in our GitHub repository). Furthermore, if the fit_zne function is implemented in a differentiable manner (using, e.g., the PennyLane math module), then the extrapolated value itself will be differentiable with respect to circuit input parameters.

In addition to using the qml.transforms module to build differentiable ZNE methods from scratch, as of v0.25 PennyLane includes a built-in batch transform, mitigate_with_zne. The transform is accompanied by custom folding functions, as well fitting options such as Richardson and polynomial extrapolation.

The differentiability of transform parameters can be leveraged for characterization tasks such as learning noise parameters. Consider a simple noisy device where every single-qubit gate is depolarized by the same qubit-dependent amount. We can simulate this noise using a transform that applies an appropriate depolarization channel after every single-qubit gate, as shown in Figure 15.

Suppose the set of true depolarization parameters is \(\mathbf {p} = [0.05, 0.02]\), i.e., \(p = 0.05\) for the first qubit and \(p = 0.02\) for the second. In the left panel of Figure 16, we choose a suitable circuit for experimentation and use a transform to learn both depolarization parameters. We first set up a representation of our noisy device and bind to it a QNode that applies the transform using the true depolarization parameters. Note that this step is merely for simulation purposes, and it can be substituted with a noisy hardware device that does not apply any transforms at all.

Next, we optimize to learn these depolarization parameters, using a simple least-squares loss for the cost. It computes the difference between the output of a transformed QNode whose transform parameters we are trying to learn (which is running on an ideal, simulated device), and the noisy QNode (which is running on a device with the true amount of depolarization noise). Optimization was performed using gradient descent, and results are plotted in the right panel of Figure 16 (full code can be found in the GitHub repository). The learned parameters are close to the true values, with variability due to shot noise. While this is a simple example, it could be generalized to more complex noise models, such as gate- and qubit-dependent noise, other types of noise such as gate over-rotation, as well as composition of noise channels.