In this application note, we’ll discuss the different types of quantum constraints, why they’re important, and how the Classiq quantum algorithm design software platform allows users to satisfy these constraints as well as to investigate the trade-offs between them.

About Constraints

We live in a constrained world. In classical computing, the abundance of sorting algorithms shows that with each constraint, there is a trade-off, with no single solution that is best for all cases. The Quick sort is very fast but is constrained by its proper implementation, the Heap sort requires little memory but can be constrained by speed, and so on. Constraints are the barriers between possible and impossible.

In quantum computing we see this in a variety of measurable properties: qubit count, decoherence times, circuit depth, basis gate sets - and so on. 

These quantum constraints dictate potential, with many trade-offs worth investigating. Perhaps a financial institution interested in optimizing portfolios by using hybrid quantum/classical algorithms cares more about qubit count than pure accuracy of the solution. Or perhaps a logistics company interested in solving satisfiability problems with purely quantum algorithms are most concerned with circuit depth, as errors add with each gate. Quantum constraints aren’t one-size-fits-all. Each quantum use-case comes with different priorities, and while each hardware vendor has different constraints, it’s worth remaining open and portable since the leader of the hardware quantum arms race shifts often.

The quantum computers of today will be replaced in due time, with evolving limits to their potential. We’ve already seen hardware with single-digit qubit counts surpassed by those now in the hundreds, with IBM expecting a 1000 qubit machine by 2023. Companies desire to squeeze the maximum performance out of existing computers with their existing constraints but be flexible enough to adapt to a new set of constraints with future generations of quantum computers.

Classiq offers a unique software platform to help companies create optimized quantum software, taking advantage of today’s machines while preparing for tomorrow’s. Using the Classiq platform, users can transition between hardware vendors and their specific constraints with ease. Classiq’s powerful synthesis engine takes in high-level functional models (e.g. a definition of what the software needs to do) and a set of user-defined constraints.  The platform then transforms this into an implementable that delivers the functionality while meeting the constraints, ready to execute on the quantum hardware vendor of choice.

Without the need to specify which gates connect to which qubits, users can focus on what can be achieved within what constraints, while the Classiq platform handles how. It does so by exploring a huge design space of possible implementations, seeking to find a method to meet the functionality as well as the constraints. Thus, when the constraints change, simply generate a new circuit using the existing functional model.

Let’s investigate a few quantum constraints and their trade-offs that can be implemented with Classiq.

Circuit Accuracy

The accuracy of a circuit can be represented in many ways and is a measure of how close our result is to our expectations. For example, in a circuit that prepares qubits into a certain state, whether through specifying the probability mass function or the gaussian mixture, Classiq offers various error metrics to call upon - the Kullback-Leibler (KL) divergence, Lp norms, and more. Today, we’ll be demonstrating how we work with the KL metric. 

Let’s say we need to initialize 3 qubits to the following state:

We can achieve this by calling the Classiq State Preparation function and specifying the probabilities.  Let’s start by defining our constraint as a maximum KL error of 1% or a 99% accuracy for each state.

Classiq offers two equivalent methods to design quantum circuits: a textual model that is accessible as a VSCode plugin or a Python SDK.

This is how this state preparation looks in the Textual Model:

{
   "logic_flow": [{
       "function": "StatePreparation",
       "function_params": {
         "probabilities": {"pmf": [0.05, 0.11, 0.13, 0.23, 0.27, 0.12, 0.03, 0.06]},
         "error_metric": {"KL": {"upper_bound": 0.01}}
       }
     }
   ]
 }

And with the Python SDK:

from classiq import ModelDesigner
from classiq.builtin_functions import StatePreparation
from classiq.interface.generator.state_preparation import PMF

model_designer = ModelDesigner()
probabilities = (0.05, 0.11, 0.13, 0.23, 0.27, 0.12, 0.03, 0.06)

params = StatePreparation(probabilities=PMF(pmf=probabilities),
                         error_metric={"KL": {"upper_bound": 0.01}})

model_designer.StatePreparation(params=params)

circuit = model_designer.synthesize()
circuit.show()
print(circuit.qasm)

When we generate this circuit, the user’s code is sent to Classiq through the cloud, the synthesis engine finds the optimal circuit, the result is sent back to the user, and the code sent to the cloud is automatically deleted, with Classiq keeping only metrics pertaining to if synthesis was successful. Here’s our result within VS Code:

We simply specified the probabilities and the accuracy, and we get this circuit with 4 qubits operated on by a variety of gates. As we wanted three qubits in this specific state (marked as q₀ through q₂), we see an auxiliary qubit, q₃, was automatically generated to help with calculations while preparing our three qubits.

Alongside our generated circuit image, we can see on the right side the Open QASM 2.0 code that implements this.

But what if we don’t have the resources to have such an accurate circuit, or prefer to preserve quantum resources for later stages in our algorithm? Let’s see how different a circuit with a 5% KL error looks.

With one small change, we can get vastly different results. We can see just how different these accuracies are by pasting our Open QASM 2.0 code into the IBM Quantum Composer.

Since it’s so easy to edit quantum circuits with functional code, users can spend much more time investigating trade-offs or creating new ideas for circuits. Let’s see another example of a quantum constraint.

Circuit Width

The width of a quantum circuit is the number of qubits in the circuit. Unlike classical circuits, quantum circuits can only flow in one direction, with the width or qubit count determining the shape of the circuit along with the depth, which we’ll discuss later. While some declare the qubit count of a quantum computer the main contributor to its strength, many factors go into determining which computer is best for which case.

Let’s say we need 3 instances of our 3 qubits state preparation above with a KL error of 5%.

We will focus on the Textual Model for the remainder of this application note, while the functionality can still be achieved with the Python SDK. We call our State Preparation function three times:

{
	"logic_flow": [
    	{
    	"function": "StatePreparation",
    	"function_params": {
        	"probabilities": {"pmf":[0.05, 0.11, 0.13, 0.23, 0.27, 0.12, 0.03, 0.06]},
        	"error_metric": {"KL": {"upper_bound": 0.05}}
            },
    	"name": "state_preparation_1"
    	},
    	{
    	"function": "StatePreparation",
    	"function_params": {
        	"probabilities": {"pmf":[0.05, 0.11, 0.13, 0.23, 0.27, 0.12, 0.03, 0.06]},
        	"error_metric": {"KL": {"upper_bound": 0.05}}
        	},
    	"name": "state_preparation_2"
    	},
    	{
    	"function": "StatePreparation",
    	"function_params": {
        	"probabilities": {"pmf":[0.05, 0.11, 0.13, 0.23, 0.27, 0.12, 0.03, 0.06]},
        	"error_metric": {"KL": {"upper_bound": 0.05}}
        	},
    	"name": "state_preparation_3"
    	}
	]
}

And our resulting circuit:

‍

But what if we’re limited to 10 qubits to create this circuit? Can we create the same functionality achieved from this circuit while constrained on width? Let’s try adding a qubit count constraint.

In our textual model, we add this line right before our logic flow.

"constraints": {"max_width": 10},

The result?

Circuit synthesis is successful. This interactive circuit can be collapsed/expanded by clicking the -/+ icon in the top-left corner of each block. We’ve saved 2 qubits, while creating a deeper circuit, with the Classiq platform automatically exploring auxiliary qubit reuse, seen here on q₃and q₇. Not only does this save quantum experts time and energy in component-level design, but this process of finding solutions under given constraints can be effortlessly achieved by experts in other domains.

Circuit Depth

The depth, as mentioned above, determines the shape of the circuit, with deeper circuits often having more gates than shallower ones. In the current era of quantum hardware, gate errors can add fast. With too deep a circuit, users can be left with nonsensical noise, so minimizing depth can be critical.

Let’s say we have 16 qubits to implement 5 different state preparations with varying KL errors as seen in the code below:

{
   "constraints": {
       "max_width": 16
   },
   "logic_flow": [{
       "function": "StatePreparation",
       "function_params": {
           "num_qubits": 4,
           "probabilities": {
               "pmf": [0.4, 0.05, 0.2, 0.05, 0.3, 0.0, 0.0, 0.0]
           },
           "error_metric": {"KL": {"upper_bound": 0.3}}
       },
       "name": "sp1"
   },
   {
       "function": "StatePreparation",
       "function_params": {
           "num_qubits": 4,
           "probabilities": {
               "pmf": [0.4, 0.05, 0.2, 0.05, 0.0, 0.3, 0.0, 0.0]
           },
           "error_metric": {"KL": {"upper_bound": 0.32}}
       },
       "name": "sp2"
   },
   {
       "function": "StatePreparation",
       "function_params": {
           "num_qubits": 4,
           "probabilities": {
               "pmf": [0.4, 0.05, 0.0, 0.05, 0.3, 0.0, 0.2, 0.0]
           },
           "error_metric": {"KL": {"upper_bound": 0.32}}
       },
       "name": "sp3"
   },
   {
       "function": "StatePreparation",
       "function_params": {
           "num_qubits": 4,
           "probabilities": {
               "pmf": [0.4, 0.0, 0.2, 0.05, 0.3, 0.0, 0.0, 0.05]
           },
           "error_metric": {"KL": {"upper_bound": 0.34}}
       },
       "name": "sp4"
   },
   {
       "function": "StatePreparation",
       "function_params": {
           "num_qubits": 4,
           "probabilities": {
               "pmf": [0.4, 0.05, 0.2, 0.0, 0.35, 0.0, 0.0, 0.0]
           },
           "error_metric": {"KL": {"upper_bound": 0.3}}
       },
       "name": "sp5"
   }
]
}

We can see auxiliary qubit reuse occur on q₃, q₇, and q₁₄, and we can use the Classiq Analyzer tool to see just how deep this circuit is - in this case 126.

Say we’re limited to a depth of 85. Let’s add a depth constraint to see if this functionality can be created another way. We specify this in our constraints dictionary.

   "constraints": {
       "max_width": 16,
       "max_depth": 85
   },

And our circuit:

We now see auxiliary qubit reuse on q₃, q₇, q₁₁, and q₁₅, and our circuit depth is 82. Not only can you easily synthesize and edit quantum circuits with Classiq, but you can also seamlessly analyze them to better investigate trade-offs specific to you.

Gate Set

Just like the specific modality to achieve manipulatable qubits varies between hardware vendors, so too do the native gate sets. These basis sets determine what manipulations are possible, with all operations composed of combinations of these gates. For example, the IBMQX5 has a native gate set of u₁(λ), u₂(λ,θ), u₃(λ,θ,Φ), and CNOT gates, while the Rigetti Agave Processor has R_x, R_z, and CZ gates. While we’re unsure of who will be the winner of the quantum arms race, being able to choose which native gates your circuit uses is essential for not being locked in with any outperformed vendors.

Say we want the following state:

We can achieve this state with a KL error of 1% with the circuit produced from the following textual model code:

{
	"logic_flow":[
  	{
     	"function": "StatePreparation",
     	"function_params": {
        	"probabilities": {"pmf":[0.45, 0.11, 0.23, 0.21]},
        	"error_metric": {"KL": {"upper_bound": 0.01}}
     	}
  	}
   ]
}

We see our output Open QASM 2.0 code, and this circuit has 2 qubits with a depth of 7 through utilizing Hadamard, RY, X, and CNOT gates.

But what if our hardware vendor has a specific gate set without these options? Can we achieve the same results from a basis gate set of CNOT, SQRT(X), RZ, and X gates? Let’s specify these gates in our code above our logic flow.

	"hardware_settings": {
  	"basis_gates": ["cx", "sx", "rz", "x"]
   },

We see this state can still be created when restricted to these gates, with a slightly deeper circuit. 

Transpilers take care of converting basic gates to universal gates, but performing this constraint on the functional level can achieve better results through optimization when circuits become much larger. While a transpiler may cancel consecutive Hadamard gates, they are unable to cancel consecutive functional blocks, like QFT followed by QFT^†.

Lastly, let’s confirm these circuits have the same functionality by copying our Open QASM 2.0 code from each circuit into the IBM Quantum Composer.

And we see the same probability distribution. The ability to change basis gates is an essential part of remaining flexible and open to multiple hardware vendors, while they often outperform one another and offer a variety of trade-offs.

Conclusion

In this application note, we learned about how quantum constraints are created from hardware limitations and how software that can easily adjust these constraints lets users explore the trade-offs between them. Whether you’re limited by circuit depth, width, accuracy or more, Classiq can adjust to your needs.

To learn more about how Classiq can help you adapt to various quantum constraints, schedule a no-commitment demonstration here or see our upcoming events here.