We are proud to announce the successful completion of our Careers in Technology Workshop at Gurugram’s Sankalp School! With the main focus of this workshop on software engineering, we gave a brief introduction of the field, its worldwide impact and potential careers to middle school children. Our goal was to ignite curiosity, establish analogies and help children see software’s role in their everyday lives, perhaps the next time they pick up their parents’ phones!

Since software is rarely introduced at this stage in a child’s education, we carefully adapted our presentation to suit young learners. Starting with light introductions and aspirations, we were amazed by their diverse responses — ranging from doctor to astronaut, scientist to army officer. Building upon their interests, we highlighted software’s pervasiveness in daily life, from mobile phones and laptops to hospitals and even superhero tech! To explain software’s career opportunities, we used a simple yet effective analogy of a pen to break down career roles into design, development, and management. This was followed by an engaging game where children classified phone components into these roles — a fun and insightful way to reinforce learning.

It was great to see the receptiveness of the children, their immense sense of curiosity and an infectious desire to learn the “why” of things. We also saw a wave of interest as we started diving into things like computer games, social media and other present day technologies. One thing which caught our attention was interest in the field of hacking. While their view was restricted, it was surprising to see a couple of 10 year olds talking about a possible career in computer security! Other than their obvious enthusiasm, it was exciting to see the sheer breadth of interests, related questions and a fluid mindset this early in their educational journey.

After conducting numerous such workshops, we have come to realize that each of them is as much of a learning experience for us as it might be for the children. We observed that a great way to mitigate children’s smaller attention span is by introducing games in discussions. Children are naturally attracted towards play and adding a touch of fun always makes the conversation more interactive and well received. Moreover, simplicity and zero jargon goes a long way when talking with young learners. Lastly, having a less rigid presentation structure and active audience participation makes things a lot more interesting.

These experiences have equipped us to better empower children to explore technology on their terms. With more workshops in the pipeline, we look forward to continuing this journey of inspiring future leaders, one classroom at a time.

Learn more about GirlsGrow on Linkedin!

Python is a versatile language consisting of a vibrant feature set. This is a catalogue of new features which I’m discovering as I go about it and the details are pretty interesting!

1. Interfaces in Python

I came across this while developing theqbraid-qir project. The pyi extension for Python files means a file where ALL method/function definitions are empty.

The i in pyi stands for interface. Taking the analogy from other languages like Java which have a concept of interface, a pyi file would contain only the structure of what a function or a class method would look like but not its implementation. I encountered this extension while going into the details of the pyqirrepository.

Another name for this is a stub . It is just a specification of what an interface is going to look like or the structure of some function. Again, no implementation details are present in it.

It can also be thought of as something like the C header files, eg-

# my_file.py
def my_method(name):
    return "hello"+name

# my_file.pyi
def my_method(name : str) -> str ...

First is the implementation, and the second is the header/interface/stub / pyi file.

2. Ellipsis in Python

Ellipsis or ... is a keyword in python. It has multiple uses such as —

As a placeholder

When we are unsure of what we would be writing in our code, we can easily use ... to denote the same. Eg —

# py_script.py
def do_something(name):
  ...
do_something("hi")

When we execute py_script.py it will correctly be interpreted and we won’t see any errors.

Another place where ... can be used in stubs. Stubs are used when we only want to define the skeleton of a particular method / function but do not want anything to be executed. This might be a requirement while building an application not yet handling external user requests. Eg —

# example file 
from some_package import external_request_counter 


if debug_mode:
  def external_request_counter(): ...

... # rest of the code 

The ... helps in making testing easier by overriding definitions and just ensuring that the structure is as expected.

https://realpython.com/python-ellipsis/#what-does-the-ellipsis-mean-in-type-hints

3. Caching arbitrary functions in Python

During the development of qBraid-sdk, I found a method which was making a GET request for retrieving the quantum devices from our rest API, and doing so every single time. This was kind of slow and we needed to do something about it.

The nature of the method was to get the devices supported by a quantum provider and it made sense for it to make a call to the API. But the device distribution does not change very much over the course of minutes, right? If this is the case, we can safely “cache” the returned devices in memory and return them if the cache has not yet expired. Seems simple enough and a straightforward implementation is to keep a last_accessed variable and time_to_live (TTL) attribute for our quantum devices.

But, what if we could cache the whole “function signature”? This is what I did finally! (courtesy of the OP Ryan Hill). Turns out we can decorate a function with anything that we want and make it “cachable”. How exactly? Let’s take a simple example —

class Multiply:
  def __init__(self):
     pass 
  def get_value(self, n):
      return n * 10

We have a very simple class Multiply whose get_value method multiplies the argument by 10. Now, we can easily instantiate and call this as —

a_obj = A()
print(a_obj.get_value(1)) # 10

This prints 10, good enough. But now, we don’t want to do this computation but want to just retrieve the return value. The idea is to store the results in a cache to be retrieved later. But its boring to just store the name of the argument as our key, as it can lead to cache collisions. Let’s store the hash of the function signature! Define a hashing function like —

import hashlib
import json

def _generate_cache_key(func_name: str, args: tuple, kwargs: dict) -> str:
    """Generate a cache key based on function name, args, and kwargs."""
    key_data = {"func_name": func_name, "args": args, "kwargs": kwargs}
    key_str = json.dumps(key_data, sort_keys=True)# Ensure consistent key order
    return hashlib.sha256(key_str.encode()).hexdigest()

The _generate_cache_key function would spit out a hash value for a function signature, example —

def my_function(n):
  return n * 10 

print(_generate_cache_key(my_function.__name__, ('n', 3), {}))

# output : 8a2c747f9adc491c838e593179c3bbca8eae018f88f4bd434729cced25492ebd

Now, we can identify a function call “uniquely” with this cache key. Here comes the interesting part! To make a method “cachable” we use the built in decorator functionality of python. How exactly? The following example would make things clear —

import functools 
import time 

def cache_results(ttl: int = 120):
    """
    A decorator to cache the results of get_device or get_devices methods.
    Args:
        ttl (int): Time-to-live for the cache in seconds.
    """

    def decorator(func):
        cache = {}
        @functools.wraps(func)
        def wrapper(*args, **kwargs):

            # Generate a unique cache key based on method name, args, and kwargs
            key = _generate_cache_key(func.__name__, args, kwargs)

            # Check if the result is in cache and still valid
            if key in cache:
                cached_result, timestamp = cache[key]
                if (time.time() - timestamp) < ttl:
                    return cached_result

            # Call the actual method and cache the result
            result = func(*args, **kwargs)
            cache[key] = (result, time.time())
            return result

        return wrapper

    return decorator

This cache_results method is a python decorator i.e. it be can be wrapped around any function that we want. We have the name of the decorator — cache_results. Post that we have the decorator method i.e. what will happen to a function which is decorated with the @cache_results(). this will have the argument as the callable or the function which is wrapped. Then, wrapper defines what happens during the invocation of this decorator. In wrapper, we first calculate the hash value of the function signature, then check if the cache entry is present AND valid. If yes, we return from there. Otherwise, we call the function and update the cache with the return value and current time. Now, if we do something like —

@cache_results(ttl = 10)
def my_function(n)
  time.sleep(5)
  return 10 * n 

init_time = time.time()
_ = my_function(1)
print("time taken:", time.time() - init_time) 
# output : 5.0021278858184814

init_time = time.time()
_ = my_function(1)
print("time taken with cache:", time.time() - init_time) 
# output : 0.0001590251922607422

We can clearly see that the second function call has come from the cache as the time taken is < 0.001 seconds whereas the original time is ~ 5 seconds (atrributed to the time.sleep()).

Why this is powerful is because of the nature of this decorator. It does not matter what kind of function we have or its return value. As long as the function call signature is hashable, we are good to go!

Some nuances which I had in my PR can be found here — https://github.com/qBraid/qBraid/pull/755. Essentially I used a different access scope for the cache due to some specific constraints but the primary idea was the same.

Hope this helps out someone else too!

Background

Quantum computers are evolving at a rapid pace in today’s post-NISQ era with a plethora of techniques to develop qubits. From superconducting circuits and photonics to neutral atoms and ion traps, each quantum computer employs a unique approach to realizing qubits. Along with different qubit architectures, a lot of packages, like Qiskit, Braket, Cirq, Pennylane and languages such as Q# have been developed that allow users to interact with these systems. These varied architectures and input formats are not a new concept in the field of computing. Different architectures exist for classical computers as well like the x86, ARM or AMD and languages such as Python, C, C++, Java and the likes. Just as in classical computing, users in quantum seek to write code that is agnostic of the underlying architecture, allowing their programs to run seamlessly across different systems.

Well, we do not write an if statement thinking whether it will be executed on x86 or ARM. Similar constructs are available in quantum like the gate based model of quantum computing. This is an abstraction which defines the behavior of a particular gate irrespective of how it is implemented; just that it is. The users are not, and need not be, aware of the hardware even though they can use quantum gates and execute circuits. It is the job of the developers writing a converter who cater to these aspects of circuit execution thus bringing us to an interesting problem of converting a high level program to executable code.

How do we achieve this architecture agnostic execution of quantum programs and is there any one way to do it? Lets find out!

Let’s first talk about how this is done in the classical systems. If we want to convert the programs written in a particular language say Python to the x86 or the arm architecture, we would need 2 compilers — Python to x86 and Python to arm. Each one would take our high level Python code, and convert its constructs according to the target architecture. The users need not be aware of these transformations because these tools would automatically detect the target system in their backend.

This is all well and good but what about when we have an arbitrary number of language formats coupled with a different number of architectures?

The number of compilers would scale as the product of these formats and architectures. Each new format would require 1 converter for each architecture it targets. Since writing a compiler is not a trivial task, it is hard to keep up with the development of packages and architectures. A possible solution to this problem is using a common intermediate representation (IR). Languages can be compiled down to this common IR before compiling it further to architecture specific representations. Why does this help? It is because adding a new format or architecture entails a “single” tool to be built. A new language would only need a single converter to the target IR and a new architecture target would require only 1 compiler.

While this problem has been solved for classical computers with IRs such as LLVM, the efforts for standardizing a common IR for quantum computers are still underway. One project which aims to realize this for quantum computers is Quantum Intermediate Representation (QIR) backed by the QIR alliance. Composed of members from various organizations such as Microsoft, NVIDIA, Quantinuum and others, their primary aim is to design and implement compiler technologies for advancing quantum programming language design and development.

What is QIR?

Quantum Intermediate Representation or QIR is a type of IR which uses the Low Level Virtual Machine(LLVM) IR. QIR is defined by something called a QIR spec which defines how to represent quantum programs within the LLVM IR. This form can utilize the existing LLVM toolchain and be converted to the executables targeting different qubit implementations.

As evident from Fig. 4, QIR exists in the middle of the user code and the backend target. It enables different quantum computing packages to lower their programs into a single IR which can eventually be compiled down to the qubit level.

How is it different from openqasm?

There are several levels in which QIR is different from the existing openqasm specification —

Focus:

• openqasm: Specializes in representing quantum circuits with a primary focus on quantum gate operations and limited classical control.
• QIR: Provides a unified representation of both quantum and classical operations, enabling integrated optimization and management of hybrid quantum-classical programs.

Optimization:

• openqasm: Supports circuit-level optimizations, mainly targeting quantum gate reductions and qubit mapping.
• QIR: Leverages the LLVM framework for advanced optimizations across both quantum and classical code, offering broader and more sophisticated optimization capabilities.

Hardware Abstraction:

• openqasm: Closer to hardware-specific quantum circuit representation, requiring backend compilation for specific QPU architectures.
• QIR: Hardware-agnostic intermediate representation that is further compiled into hardware-specific instructions, offering greater portability across different quantum platforms.

Come in qbraid-qir

At qBraid, we aim to develop platform agnostic resources for quantum computers. Whether it be our quantum software development kit i.e. the qbraid-sdk or a unified platform providing access to a variety of quantum computers all within the qbraid lab, our goal is to enable a seamless access to users without having to worry about dependencies, multiple software packages or how to access different quantum computers. So when an IR was being developed to standardize quantum program translation, we couldn’t help but pitch in!

We are rapidly developing a python package called qbraid-qir which enables people to convert quantum programs directly to QIR. It currently supports conversions between cirq and openqasm to QIR programs. Users can supply quantum circuits or code, written in either of the packages, and the converter takes care of generating a semantically valid QIR program. Here’s a simple example to convert a bell state circuit into QIR —

# Run: pip install qbraid-qir 
from qbraid_qir.qasm3 import qasm3_to_qir

program = """
OPENQASM 3;
include "stdgates.inc";

qubit[2] q;
bit[2] c;

h q[0];
cx q[0], q[1];

measure q[0] -> c[0];
measure q[1] -> c[1];
"""

module = qasm3_to_qir(program, name="my-program")

ir = str(module)

Besides direct conversions, we can also utilise qbraid-sdk’s abilities to extend this conversion to other packages. Although qbraid-sdk supports conversions between popular packages such as braket, cirqand qiskit out of the box, it can perform arbitrary conversions given that we specify a conversion method for the source and target packages. For example, we can add the conversion function for cirq to QIR into qbraid-sdk’s package conversion graph and convert a braket circuit to QIR. Here’s an example notebook for converting braket circuits to QIR that uses the qbraid-sdk and qbraid-qir packages.

Current State

The development for qbraid-qir was started in Dec 2023 with the cirq to QIR converter. Since then, we have expanded to openqasm conversions and are currently at v0.2.2, after our first release back in Jan 2024. Housing a semantic analyser for openqasm, our converter supports a wide range of semantic checks based on the OpenQASM3 specification and we aim to target the full breadth of those operations.

qbraid-qir can be easily installed using pip, allowing users to quickly start local development. Moreover, the qbraid-lab provides built-in support for qbraid-qir package in our default environments. Users can access the package in cloud and even submit jobs to the remote QIR simulator available at qBraid.

Future Scope

We aim to release the first stable version of the openqasm to QIR converter sometime around Oct 2024. This version will provide complete support for openqasm constructs which can be converted down to QIR and enable complex openqasm programs to be transformed and executed in equivalent QIR code. Subsequently, we also want to expand the capabilities of the cirq to QIR converter. While we support many native cirq gates, the converter would benefit from tackling more complex gate conversions and supporting a larger number of cirq constructs.

During the development of the converter, we also identified that the semantic analyser for openqasm could potentially be de-coupled from the qbraid-qir package. Although the current implementation has some coupling with the QIR python bindings, our eventual goal is to split the semantic analyser into a separate package. This will enable independent usage of the openqasm checker and allow it to be used either as an independent analyser or as a dependency in other packages which require semantic analysis for QASM programs.

We believe that standardization in quantum program representation is the way forward for a scalable and platform independent development of the field. QIR is an initiative which does exactly that and thus at qBraid we want to enable a seamless integration with existing quantum computing packages and pave the way for future tools looking for an established IR for their quantum programs.

The Qiskit Transpiler is an essential tool that allows us to map any arbitrary quantum circuit into a circuit that is both physically runnable and compatible with the properties of its target quantum backend. Qiskit’s transpiler has built-in logging and callback mechanisms to help users understand transpilation, but, many users don’t know about these methods, nor do they have sufficient knowledge about using them. That’s where we come in.

The process we use Qiskit’s transpiler for is called quantum circuit
transpilation. It includes important tasks like expanding a circuit to the backend’s qubit count, breaking down higher-level quantum operations in terms of the supported basis set, routing qubits according to the chip connectivity, and optimizing the final circuit. Users often find it difficult to visualize these tasks, however. That’s why we decided to build Qiskit Trebugger (transpiler-debugger), a tool that provides a visual representation of the transpilation process. Originally debuting on the Qiskit blog in early 2022 in the form of a Jupyter widget, we’re pleased to share that Qiskit Trebugger is now also available as a lightweight command-line interface (CLI) as well.

Qiskit Trebugger was developed as an interactive tool with multiple views catering to the needs of different users. Available as a Python package on PyPI, it can be used as a Jupyter widget or a lightweight CLI tool to understand how a circuit goes through the Qiskit transpiler. Below, we’ll take a closer look at this new CLI functionality and its key features.

Command Line View

The command line view for the debugger is a recent development. Built using the ncurses and tabulate packages, it is a lightweight alternative to the Jupyter view. It has minimal overhead for loading and gives users the ability to debug circuits in a familiar terminal environment.

The CLI view is also interactive, with action keys for navigation and a status bar. Users can index into the pass list to see the details of each pass and toggle through different views. The CLI supports most features that are provided by the Jupyter view. However, users should note that they can only render the CLI view in the terminal, not a Jupyter notebook.

Installing the package is as simple as running the following command —

pip install qiskit-trebugger

To test the package, users can run a Python file with the given code —

from qiskit.providers.fake_provider import FakeCasablanca
from qiskit.circuit.random import random_circuit 
from qiskit_trebugger import Debugger
import warnings

warnings.simplefilter('ignore')
debugger = Debugger(view_type = "cli")
backend = FakeCasablanca()
circuit = random_circuit(num_qubits = 4, depth = 5 , seed = 44)

# replace qiskit's transpile call 
debugger.debug(circuit, optimization_level = 2, backend = backend)

This will render a view describing the transpilation process of the Qiskit transpiler.

Components

• Overview Panel: The overview consists of the header and the transpilation overview panels. The transpilation overview panel highlights crucial information about the workings of the transpiler. It consists of the total number of transpiler passes executed, the total runtime of the transpiler, and a comparison of the different statistics for the original and final circuits.

• Global Transpilation Panel: Provides the details about which passes were executed during transpilation and in which order. Key details such as pass type, runtime for the pass, and circuit statistics post-execution of each pass are highlighted in a tabular format. Passes that change at least one property of the circuit are highlighted as well.

• Interaction Bar: The CLI tool is interactive and can take in user input to modify its state. This input is taken through ‘hot keys’ listed in the interaction bar at the bottom of the terminal. The commands are listed below :

1. Arrow Keys: Scroll horizontally or vertically
2. U: Page Up
3. D: Page Down
4. H: Toggle the overview panel
5. I: Index into any transpiler pass
6. N: Move to Next
7. P: Previous pass while viewing pass details
8. B: Move back to the initial view
9. Q: Quit

Note: After pressing I, the user can enter the index of any transpiler pass and the pass level details will be rendered for the same.

• Pass Level Panels: These panels display a more granular level of detail. The user indexes into a particular pass by pressing ‘I’ followed by the index of the transpiler pass. This renders a new panel where users can see the state and properties of the circuit after this pass is executed. Trebugger highlights circuit statistics and property set for the given pass. Moreover, it also expands properties like the layout and original qubit indices, providing an insight into the detailed mapping of the circuit’s virtual to the physical qubits of the quantum backend. Lastly, circuit diagrams, documentation, and logs are displayed for an easier lookup.

Future Work

The project's development is ongoing with more upcoming features in both the CLI and the Jupyter view on the way. These include expanding different elements in the property set in the CLI view and introducing new elements in the jupyter widget such as the backend coupling maps, timeline drawer for the qiskit pulse schedule, and routing maps for the qubits. We encourage anyone interested in contributing to the project to do so via the GitHub repository linked below.

Sincere thanks to Unitary Fund for supporting this project through their Microgrant Program and facilitating the opportunity to work on it. Thanks as well to the Qiskit team for their support in the Qiskit Advocate Mentorship Program, and to mentors Kevin Krsulich and Matthew Treinish for their constant guidance and feedback.

Reference Links :

Qiskit Blog Post | GitHub Repository | Python Package | Demo Video

New features of the Qiskit Trebugger was originally published in Qiskit on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quantum computing is a paradigm which utilises quantum objects and their properties to carry out computational tasks which may be very time consuming or even impractical for classical computers. Quantum superposition, interference and entanglement are the 3 major properties which are used to achieve the same. Here, in this blog, we talk about quantum entanglement in more detail.

Quantum Entanglement

I’m sure a lot of you reading this blog post have a broad idea about quantum entanglement, which goes something like the following —

Any two quantum objects may become entangled and any change in the state of one particle instantaneously changes the state of its entangled counterpart.

Let us dissect it and understand what does this really mean?

In simplest of forms, entanglement means some kind of correlation.

For a simple example, consider any pair of particles, say A and B. We assume that these are sufficiently small, like electrons, and their lives are directly governed by quantum mechanical properties. If particles A and B are entangled with each other, it means that any change in the state of A or any action on A will affect the state of B. That’s all fine, we observe this in our daily lives. For instance, hitting a billiard ball affects the state of the ball in comes in contact with. But can it happen instantaneously? Without any communication or information transfer? Without contact of the balls? Quantum Entanglement does.

Irrespective of the magnitude of the distance present between the entangled particles, the change is instantaneous or non — local. This is what is puzzling. How can it happen? Does the pair actually contain some hidden information which gets transferred? All this was pondered upon by Einstein and his colleagues.

Einstein, Podolsky and Rosen on Entanglement

Come in Einstein.

He was a realist and believed that the world was governed by local realism —

• local means that any event or action or effect or any change in our vicinity (at arm’s length/in the room/near the building) does not affect something (body/reaction/process) which is far away or sufficiently separated from the former event. By far away we mean that any effect can not be felt in a time lesser than that required by light to travel between the cause and the effect.

• realism means that the world exists even if there is no observer. Means that even if no one is looking at a tree, it must exist. Similarly for quantum particles it means that even though we have not observed the particle, its definite state must exist.

Coming back to entanglement.

According to Einstein, entanglement was something like correlation at origination. Building upon the ideas of local realism, his explanation was that the entangled particles must have emerged as the states which we are observing them right now, instead of any kind of instantaneous change.

According to him the entangled particles must have started off in the same set of states as measured and that no collapse of the state vector had occurred.

Moreover, using these two principles as universal truths, Einstein along with Podolsky and Rosen (EPR), claimed that quantum mechanics might not be complete, even though it was correct. To understand this, we can take an analogy. Think of an apple. A theory says that an apple is a red looking object. While this theory is correct, but it is not complete. An apple is characterised by many properties such as weight, size, sweetness, etc. which are indeed relevant to any human interacting with it. So while saying an apple is red, may be correct, but not complete.

As some of you may know, a very crucial aspect of quantum mechanics is the concept of measurement. Following the Copenhagen Interpretation of Quantum Mechanics, it is widely accepted that the state of a quantum particle is not well defined until it is measured. Measurement itself forces the particle(s) to choose one of the several possible states in which they can collapse. These pioneers conjectured that even though quantum mechanics gave correct results and agreed with experiments, it was not in line with realism. So what were indeed their explanations and what was the quantum mechanical view of particles? Let us see —

An Experimental Setup

Take a pair of particles which are entangled. While not going into the experimental details of creating such entangled pairs, we are assuming we have something like a generator. This device would produce entangled pairs of particles for us to play around with. The physical property which this device deals with is the spin and what is actually entangled is the spin of the pair of particles.

Say that the particles are entangled such that we have perfect anti-correlation. This means that if one of the particle has an up spin (↑) along an axis, the other would necessarily have down spin(↓) across that same axis of measurement. Also assume that we have 2 detectors situated at some distance from the generator, with one on the left and the other on right. Note that the generator and the detectors are located in a straight line. The last assumption we make is that the detectors are synchronised — whenever one detector measures a particle, the other detector simultaneously measures another.

Einstein’s View

Einstein could not accept randomness which is associated with quantum mechanics. Whenever a wave function of a quantum object is measured, he conjectured, randomness isn’t associated with it. According to him, what we had measured was exactly how the state of the particle existed before measuring.

With respect to our experiment it means that the although particles are correlated, the result we obtained at measurement was always present since the time of origination of the particle pair. During the generation of the entangled pair it may have been randomly assigned, but once set it does not fluctuate.

This means a pair with spins ↑↓ remained as ↑↓ after getting generated. Moreover, when we measure the particles we measure a property as it was already set. There is no ‘spookiness’ here (to quote Einstein!).

Quantum Mechanical View

Here things are a bit different. Quantum Mechanics says that we do have anti-correlation, but during the time when the particle pair is not measured, its states are not definite.

Whenever we measure one or both the particles, not only do we get a definite answer, but the answer is defined by the act of measurement itself. Measurement forces the system to choose from one of the possible states. For our simple experimental setup, this means that if we measure one particle as ↑ along an axis, the other one is bound to be measured as ↓ along the same axis. This was the thing which bothered Einstein.

For instance, in the above measurement setup, we did measure particle 1 as ↑. Now, we also simultaneously measured particle 2, and detected it as ↓. Einstein could not get to terms with the fact that measurement of one particle affects the quantum state of the other particle instantaneously. To say in terms of a concept which we just went over in the above post, the interaction is non-local. This problem or rather the mystery about the real nature of entanglement or reality remained a mystery for a long time, as it was really hard to test.

Why was it like this? Well, because it was difficult to test something when testing itself breaks the thing we want to test. Let’s take an analogy to clear that up.

If you measure a particle you get a certain definite value or a result, here ↓ or ↑. But doing so, you have lost the information about the nature of what you’re measuring, what was it like before measuring. Its like saying — Hey! I actually have 3 hands when you’re not looking, but as soon as you look, I only have 2. One of the hand vanishes and you see me as a normal human being. The other person will not have any way to test this. This is because the act of seeing or looking at your hands changes the number of hands itself!

This was all about entanglement where we talked about what it means for particles to be entangled and about two very popular yet contradicting views about the real nature of entanglement. Which one of them was correct? This seemingly difficult question was answered by John Stewart Bell in 1964.

Bell said that it is indeed possible to test the Einstein’s view of entanglement and that is what led to the formulation of the Bell’s Inequality and the experiments trying to prove them. What were the ideas behind these inequalities and experiments which settled the dispute about the nature of reality, once and for all? That’s the story of another blog post!

Till then, keep thinking :)

Quantum computers are devices developed with a fundamentally different set of building blocks than classical computers. Properties such as superposition, entanglement and interference, and the ways to manipulate and combine a quantum computer’s individual components are what make these systems more powerful than classical ones. But before going deeper into our topic of errors, let’s have some high-level understanding of quantum computers and compare them with their counterparts.

The article assumes that the readers have a basic knowledge about some concepts and notations used in quantum computing such as state vectors, quantum gates and measurement. If you would like to brush up on these topics, feel free to go through some awesome content by Quantum Untangled!

Introduction

Let us discuss the components of our 2 systems on the physical level.

Classical computers employ bits as their unit of computation. At any point of time, these bits are in a state of 0 or 1. But their quantum cousins behave a bit differently. Quantum computers use qubits as their units of computation which can exist as 0, 1 or in a superposition of the states 0 and 1 simultaneously, until observed. Let us see how these units are processed.

Classical computers use a set of gates such as NAND and NOR for the basic computing operations. While these gates can implement any boolean logic at the processor level, they are utilised primarily for classical bits. The case for qubits is a bit different (pun intended!). Since qubits follow the laws of quantum mechanics, their transformation has to be done via a specific type of quantum operation. These operations try to act on both of the states of a qubit simultaneously and can be modelled as unitary matrices.

Finally, we have measurements. In classical systems, if there is a voltage representing 1 state of a bit, it would still be at 1 if we try to read this state. This is not always true for qubits. According to the most widely accepted interpretation of quantum mechanics, a 2-level quantum system (qubit) would collapse to one of its 2 basis states when observed. An analogy would go something like this — you take a coin, toss it and then look at it in mid-air. As soon as you look at the coin, it would produce a head or tail in your hand. But you’ll not be able to look at it spinning!

With these fundamental elements of quantum computers described, let us look at how they are realised in an actual device.

Realisation of Components

Qubits are generally modelled with a physical system which follows the laws of quantum mechanics and has 2 distinct energy levels. This can be anything ranging from artificial atoms, photons, real atoms and even ions. Each of these systems coupled with a property, act as the qubit. For example photons can be a system and their polarisation the property. Along with this, the two states of this property act as the 2 computational states 0 and 1. Extending the above example we may have vertical polarisation of photons as the 1 state and horizontal polarisation as 0.

Besides the qubits, there also exist control electronics which try to manipulate the quantum states of these physical systems and introduce entanglement between different qubits. For an example, consider the superconducting qubits. They employ microwave pulses to change the state of the qubits and thus perform 1 and 2 qubit operations.

Lastly coming on to the measurements. To obtain useful results from any quantum operation or algorithm, they are followed by measurements. These can be done in various ways depending upon the implementation of our qubit and are again made by keeping in mind the property which was used to model the qubit. For example in the superconducting qubits, measurements are done via microwave resonators whose resonant frequency depends on the qubit state being measured.

Even though the above knowledge gives us a glimpse of how quantum computers are realised in practice, we should still keep in mind that we are trying to model quantum mechanical systems. Systems such as individual atoms or photons are extremely fragile objects. To have any kind of useful information processing, they have to be isolated from the external environment. This isolation may not be perfect and from here, arise errors.

Source of Errors

A famous quote by Asher Peres states that —

Quantum phenomena do not occur in the Hilbert Space, they occur in a laboratory

Building on the above statement let us look at how errors creep into quantum computers on the physical level.

Qubits

We noted that quantum mechanical systems are used to model a qubit and the fact that they have to be isolated from the external environment. If this does not happen correctly, the qubits may exchange unwanted energy and their states may get disturbed. In can also happen that due to this noise, the preparation of qubits in some initial state may not be exact. Moreover, the superposition states may deviate from the targeted superposition, or even completely change to basis states.

Gates

It can happen that the operations which we are trying to perform may not be exact. This may be because that the amount of change which the operation was supposed to perform was not exact. Taking the example of superconducting qubits, it may be so that the microwave pulse provides some extra x amount of energy while during a quantum operation. For a more concrete example, suppose that a quantum gate is supposed to put a 0 state into the equal superposition of 0 and 1 state, but instead it transforms the state as —

This can lead to imperfections in the quantum operations and the source of these errors could be due to errors in the classical control equipment. This is one of the major reasons that quantum gates need to be calibrated for errors.

Measurements

Lastly, measurement operations may be faulty. Suppose that we are trying to read a qubit in an array of qubits. We may report the value of the readout as 1 when in fact the qubit was in a state of 0. This is true not just for the 0–1 measurement basis, but for any basis across which we try to measure our system. This would result in errors in identifying probability distribution of the final results and measurement error mitigation would be required to deal with such errors.

In this blog, we talked about the basics of realising a quantum system, looked into how different components are modelled in practice and delved into the sources of errors in this modelling. I hope that with the above knowledge you are able to appreciate the complexity behind developing quantum computers and the need for error correction in today’s NISQ era.

Stay tuned for the the next entry where we will introduce different categories of quantum errors and look into the State Preparation and Measurement (SPAM) error in quantum systems. Till then, keep exploring!

Quantum circuit transpilation is the process of rewriting high-level quantum circuits into equivalent circuits which are compatible with a specific quantum backend. Qiskit uses a tool called the qiskit transpiler for achieving this transformation. Though important for realizing physically runnable circuits, its methods remain hidden from the general user. We developed TreBugger, a Qiskit Timeline Debugger, to address this underlying issue.

We developed the Qiskit Timeline Debugger as a mentorship project during the Qiskit Advocate Mentorship Program Fall ’21, under the guidance of Kevin Krsulich. Built as a jupyter widget, it tries to make the transpilation process more transparent and accessible, regardless of a user’s background.

How? Let us find out!

Why the need?

• The ability to play around with a concept can be an important way to learn about it. But, the transpiler currently stands almost as a black box tool. While there are some methods to see its inner workings, they are accessible to the users more proficient in programming.
• A quantum computer can only run a discrete set of quantum gates. This decomposition of arbitrary quantum gates to the basic gate set can sometimes be expensive in the terms of the final number of operations required to model them. Identifying and optimizing such operations can allow us to better adapt our circuits for today’s noisy, intermediate-scale quantum backends.
• Finally, there exists a need for better error handling in the transpilation process. Trace backs in code may bewilder a user when a transpiler runs into an error. A structured way to understand these problems is necessary.

The Debugger

We present a lightweight Jupyter widget in the form of a debugger. It is built with the python ipywidgetsmodule and aims to address all the issues we hope to resolve. With an in-depth analysis of different transpilation stages and a simple, easy to use user interface, any user can quickly set up a debugger instance with as little as 4 lines of code. In the remainder of this section, it is assumed that the reader is familiar with python environments and using Qiskit. If not — get started with Qiskit here!

You can download the debugger via pip using —

pip install -i https://test.pypi.org/simple/ --extra-index https://pypi.org/simple/ qiskit-trebugger

The following code fires up the debugger in the python environment where it was installed. Simply replacing the call to the transpile method with the debug method of Debugger —

from qiskit import QuantumCircuit
from qiskit.test.mock import FakeCasablanca
from qiskit_trebugger import Debugger

debugger = Debugger()
backend = FakeCasablanca()

circuit = QuantumCircuit(3)
circuit.h(0)
circuit.cx(0,1)
circuit.cx(1,2)
circuit.measure_all()

# replace transpile call 
# circ = transpile(circuit, backend = backend)
# with debug method

debugger.debug(circuit, backend = backend)

Taking a small overhead of visual rendering, it quickly loads up the transpilation sequence of the circuit as it goes through different passes of the transpiler. As you can see, the widget is divided into three broad components which are —

• Description of the circuit, backend and transpiler arguments provided during transpilation.
• Transpilation Overview for the final circuit which provides a quick summary of the complete process.
• Main Passes of the transpiler, where each component contains a description of circuit state (depth < 300), properties, logs of pass and documentation.

Let us unwrap its features and design.

Features

1. Visual diff for quantum circuits

• Inspired by the git diff command for highlighting changes in two versions of a file, we built a custom feature called visual diffs which highlights the changes made to quantum circuits.
• We built the visual diff feature using the DAG representation of circuits and the qiskit matplotlib drawer, allowing users to visually see what changed between two quantum circuits during transpilation. Realizing what exactly changed after each transpiler pass will allow users to get more familiar with the transpiler.

• For the more curious readers, visual diff uses something called the Longest Common Subsequences (LCS) over the DAG of quantum circuits. Treating DAG as a string of one-depth circuits, the LCS contains what is common in two circuits. Everything else is just the diff !
• Currently, our debugger supports this functionality for ≤2000 depth circuits and for easy exporting, circuits are available in different formats such as png , qasm and qpy.

2. Log based analysis and documentation

• The qiskit transpiler is not a perfect black box after all, it just takes a lot of work to fully understand. It does have a built-in logging functionality which allows anyone to see the steps it takes while processing circuits.
• Logs are just text-based messages or records that define what a particular software is doing. The transpiler publishes these messages at each stage, allowing us to look under its hood. TreBugger publishes this information as a separate panel in the pass tabs.

• Each log record has a level of severity, which defines the kind of information it contains. In our debugger, we color code each log according to this severity level thus, adding a greater level of granularity for the whole process.
• Each pass panel is further coupled with a Help tab which contains the docstring of the transpiler pass. This allows the user to easily see what the aim of a particular pass was and the target return value.

3. Circuit statistics and Property set

• The debugger presents a lot of important information at the first glance, such as circuit size, depth, number of operations and time taken to run the particular transpiler pass.

• The debugger lets a user easily identify the passes which highly affect the final gate count or are particularly time-consuming. Isolation of such passes would help in targeted research towards specific transpiler optimizations.

Contributions and future work

We have built the debugger using jupyter widgets along with some basic web development tools (HTML and CSS). Anyone comfortable with python, web development and having a working knowledge of quantum computing concepts is more than welcome to contribute to our project.

Since our project uses the MVC architecture, we would love to also see a command line version of the debugger. This view would purely be based upon python and use text-based logs and properties to allow users see how a circuit evolves.

Another need for the Trebugger is UI testing. Frameworks like Cypress and SeleniumBase were decided but the tests are yet to be formulated. Once completed, the project would directly be available to be installed from the actual python packaging index, PyPi.

If you would like to contribute or be up to date with the progress of our project be sure to check out the Qiskit Timeline Debugger GitHub repo. We hope that this project opens up the workings of qiskit transpiler to the general public and makes it a more accessible tool for qiskit users.

This project is part of the Qiskit Advocate Mentorship Program Fall 21 cohort. If you are interested in joining the Qiskit Advocate program, please check out the application guide. You can also fill this form to get an email update when the new application round opens later this year.

New Debugger Takes You Under The Hood of Qiskit’s Transpiler was originally published in Qiskit on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last few posts of the series, we touched upon the relevant tools required for QPE, some mathematics, and two of the most widely used QPE algorithms. This post is dedicated to the original phase estimation algorithm proposed by Alexei Kitaev and delves into the workings, advantages, and some limitations of the original phase estimation approach. It is assumed that the reader is familiar with the basic concepts of quantum phase estimation and linear algebra. Also, if you have been following the series up until now, you shall be good to go! Let’s get started then.

Ideas and Mathematics

To remind you of our original problem, what we have is an unknown unitary matrix U and we want to find the eigenvalues of our matrix. Since any eigenvalue of a unitary matrix has unit modulus, it can be represented as follows

If we are somehow able to determine θ, we would be able to find the eigenvalue of the unitary matrix U.

Although the basic and iterative QPE algorithms build up our phase either bit by bit or encoding it into multiple qubits, Kitaev’s QPE (KQPE) algorithm relies on some classical processing to obtain a decimal representation of the phase. The readers familiar with QPE would appreciate the nature of the processing involved in KQPE as it is the inspiration for the previous two approaches. Let us go ahead and start from the basics.

Given below is the simple quantum circuit used for the phase kickback procedure:

Going through the gates in our circuit mathematically we get:

You can clearly see that the first qubit has some kind of information encoded into the relative phase of its state. But if we look closely, it is not enough. Why? This is because this relative phase has no observable effect when we try to measure only the first qubit:

Can we do something to make the factor containing θ appear in observable quantities i.e. probabilities of measuring 0 or 1? Try adding a Hadamard gate on the first qubit just after the controlled unitary gate. What do you see? Work on the math a bit before seeing the result below! In the following image, we see the effect of the Hadamard gate on the first qubit:

Now we do have something! If we see carefully see the measurement probabilities we have:

How does this help? Let us digress a little bit to brush up on some mathematics to fully understand and thus make use of these equations to evaluate our phase, θ.

Euler’s Identity and Trigonometry

Leonard Euler, one of the greatest mathematicians of all time, had devised a beautiful equation, now known as Euler’s formula. It is a very simple formula that relates the exponential of a real quantity with its corresponding cosine and sine values:

If we try to do some twists and turns, we arrive at:

Doesn’t this look strangely familiar? It does and is exactly the probability of measuring the first qubit in our circuit as 0! This is pretty great as we have expressed the phase in a well-defined function for which an inverse exists. We shall get into the details of the above relation in a bit but first, let us state some useful trigonometric identities which will be used for further calculations in the KQPE algorithm:

Initial Results

Now that we have the tools, let’s see the final measurement probabilities in terms of trigonometric functions:

Using the above two equations we arrive at the result that:

Although we have the probabilities expressed as a function of cosθ, there is a bit of a problem here. Since cosθ is equal to cos(-θ), even if we evaluate arccos(2P(0)-1) or arccos(1–2P(1)), we won’t be able to distinguish whether the value pertains to +θ or -θ. This is because cosine has a positive value when the argument lies in the first or the fourth quadrants.

This limitation brings us to think about an alternative approach. If we could somehow encode the phase information in some other function that allows us to distinguish between +θ and -θ, we would be able to recover θ from the probabilities. Given that we are fairly deep in trigonometric functions, thinking of sine and tangent would be wise. Let us try for sine!

Building a modified circuit

The thought that would lead us to a different circuit for encoding phase as the sine is that:

Well, if we had a factor of i (iota) associated with exp(iθ), it could very well be written as:

to obtain the desired function of ‘sin(θ)’ in our results. (this is because of the fact that cos(θ + π/2) = -sin(θ) ). Follow along to see how!

Let us try to work backward and see this idea in action. We know that for trying to uniquely identify the phase of the unitary matrix, we want the following expression:

which means that the system should have been in the state:

just before measurement. How would that be possible? If we regroup the terms a little bit we shall see that:

The above equation means that if we had applied an H gate to the state:

we would get the state that we desire. Comparing the state of qubit 1 in the above image to the state of qubit 1 in the image (3), we can observe that only the |1⟩ state is affected by a factor of ‘i’. This transformation can be modeled as:

For the readers familiar with the Clifford Gates, the above representation exactly matches with the S or the Rz(π/2) gate, up to a global phase. This is exciting as applying this S gate to qubit 1, just before the controlled unitary matrix, transforms the state as:

Now that we have arrived at the change that we would require in our circuit, let us look at the final result and the math to solidify our understanding:

Finally, we have the probabilities of obtaining a 0 and 1 for the first qubit as:

This lets us distinguish between the values of +θ and -θ as positive θ would correspond to a positive value ( in the domain 0,π) and negative theta would correspond to negative values ( again in domain 0,π). Going forward with our last stage of calculation and using something called the inverse trigonometric functions, we see that:

There is also a small caveat to using the inverse trigonometric functions. They are only defined for a certain domain of the input values. For those of you who aren’t familiar with inverse trigonometric functions, they are just like an inverse mapping of the outputs of the trigonometric functions to their respective inputs. For instance, since sin(x) is bound by [-1,1] in the output, the inverse of sin(x) (arcsin(x)) has its input bound by the output of sin(x). These domain conditions are always going to be satisfied for our inputs as:

We may also employ the inverse tangent or the arctan(x) function to evaluate theta values in the following way:

The reason for trying to use arctan is that the arctan function is more robust to errors than the arcsin function. If we have an error of, let’s say, s in our measured fractions and we plot the difference between the arctan and arcsin values for the actual and measured results, we would see something like:

This clearly shows that if we have an error in our measurements, the arctan function is a more robust function to use for the evaluation of our results. This leads us to the end of our KQPE algorithm with the final phase presented as :

where the symbols have the relevant meanings as mentioned in previous images. Note that these probabilities are experimentally determined and thus we can indeed find out the phase of the unitary matrix using the simple equation above. This is Kitaev’s original approach for quantum phase estimation.

I hope this approach to solve the QPE problem made you ponder about how simple classical processing may sometimes pose an equivalent way to approach quantum computing problems and reduce the complexity of our operations by reducing the size of our quantum circuits.

During all our discussions with QPE algorithms, one thing which we skipped was the accuracy of our approach. How many measurements do we really need to make to get a good accuracy of the phase that we are trying to measure? How erroneous is our algorithm in measuring the phase that it is trying to evaluate? These are just the questions to be answered in our next post on the error and accuracy of QPE algorithms.

As always, stay tuned for more by Quantum Untangled.

For those of you who are curious, please follow this link to see the algorithm realized with IBM’s qiskit. Click here to go to the repository with the full code.

Kitaev’s Phase Estimation — QPE algorithms was originally published in Quantum Untangled on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the third installment in our QPE series and revolves around a very interesting approach towards phase estimation. Some prerequisites for this article are phase kickback and basic phase estimation algorithm. Also, if the reader has followed the series up until now, they should be able to understand and appreciate the Iterative Quantum Phase Estimation (IQPE) Algorithm. Let’s get started then.

Motivation behind IQPE

Let us backtrack a little bit and see our basic QPE circuit, which we talked about in our last post.

The above circuit is used to estimate the phase of a single-qubit unitary matrix up to 3-bit precision. What this means is that n qubits are required to measure the phase up to n-bit precision. Although the basic QPE algorithm is a very important procedure, it is a bit troublesome to implement for today’s quantum computers.

We are currently dealing with quantum computers of the NISQ (Noisy Intermediate Scale Quantum) era. The qubits that we have are, still, not perfect and prone to many errors, either due to noise or due to the system not behaving quantum mechanically after a certain amount of time. Since these errors are an inescapable fact for our present systems, having a larger number of qubits interacting with each other increases the error probability to a great extent.

Anyone familiar with the experimental realisations of gates would know the fact that multi-qubit gates are the hardest to implement. Since they are hard to fabricate, multi-qubit gates are the ones with the largest errors. Moreover, since any multi-qubit gate can be broken down into CX gates (2-qubit) and single-qubit gates, we mainly characterise the errors of a system using the largest amongst them, i.e., the CX errors. Now, imagine if we have n extra qubits in our algorithm. Since a CX gate is applied between two qubits, each pair of qubits would have a different CX error.

Since our QPE algorithm employs n extra qubits, we would be getting varied results at the end due to fact that different qubit pairs have different CX errors. What if we could constrain the number of qubits we use? This motivation leads us to the IQPE algorithm.

Idea behind IQPE

Let’s trace back our steps to the basic QPE algorithm and remember what the circuit meant in a general QPE setting; the image below may help you remember this. Let’s say we had the qubit Qj representing the jth bit of our phase. The circuit would be like the following:

The 4 steps that are highlighted in our algorithm, i.e., state preparation, phase encoding, controlled inverse rotation, and measurement in H-basis, are what make one bit-identification step. To reduce the errors, we want to somehow constrain the use of the extra qubits. If we watch closely, steps 1 and 4 are performed on a single qubit, and can not be reduced further.

Step 2 deals with encoding the phase into a control qubit and, without question, requires the presence of the eigenvector and the controlled unitary to apply phase kickback. We are only left with step 3. Can we somehow reduce the number of qubits required in our algorithm modifying step 3? Let us take a closer look at what happens in step 3, i.e., the controlled inverse rotation step.

If you remember the definition of these CROTk gates, you would understand that these inverse rotations are dependent on the previous bits that we have determined before the jth bit — (j+1), (j+2), …, (n). Also, note that these controlled rotations just apply a rotation of

in a number of steps

Okay, here is something we could optimise in these applications. If you think, instead of applying (n-j-1) controlled rotation gates conditioned on (n-j-1) qubits, why not apply these gates conditioned on classical bits? What we could do is instead of using the qubits to condition our gates, we measure a qubit, store its bit value in a classical register and use that to condition the rotation gate. We will see how in a moment, but we can see that the modified circuit would look something like this

Let us explore a simple example to bring into perspective all the ideas that we have discussed till now. Let us say we want to find the phase

and we are determining the least significant bit in our phase. This is going to be the first step in our estimation procedure. The phase that is encoded up to the single bit is just

and as we saw in the basic QPE, this does not require any kind of inverse rotation gate. To recapitulate, the circuit looks something like

Coming to the next bit, we have our phase encoding as

Now, since this is not a single bit, we need an inverse rotation of

to determine our second last bit in the phase. But, instead of using a rotation gate controlled by the ‘state’ of the previous bits, we use a gate controlled by the ‘result’ of the previous bits. What I mean by that is we use a classically controlled rotation gate instead of a quantum controlled rotation gate. Why does it help? This helps because errors do not creep up as often in classical computation as they do in quantum computing. After changing our gate to a classical controlled rotation, this is what our circuit looks like

As you will notice, this idea of using classically controlled rotation gates helps us in reducing the number of qubits to just 1 for determining our phase, bit-by-bit. The following image represents the circuit for the third last bit in our phase and if you have understood the workings till now, it should be easily comprehensible.

Now that we are familiar with the circuit quite a bit, let’s look at the mathematics for a general jth step to solidify our understanding.

Each of the bit-identification steps that we saw above comprises one iteration in the algorithm. Each iteration result gives us 1 bit of the original phase and that is why this procedure is called Iterative Quantum Phase Estimation. Before seeing the differences in the basic QPE and iterative QPE, I would advise you to make yourself comfortable with the idea of a classically controlled rotation gate which is surely going to help in understanding the details a lot more.

Differences and Details

The ideas behind our Iterative Phase Estimation scheme are quite similar to the basic QPE algorithm but some of the major differences lie in the implementation parts. Majorly:

• If we say that the unitary matrix is m-qubit in size, then the total number of qubits required in the IQPE algorithm is (1+m) whereas the same requirement of qubits for the same matrix goes up to (n+m) in basic QPE for n-bit precision.
• Unlike basic QPE, IQPE relies on classically controlled rotation gates instead of the original quantum controlled rotation gates
• The phase of the unitary matrix U is determined one bit at a time in IQPE and the results of measurement are required to proceed with the algorithm further whereas, in traditional QPE, the ancillary qubits are measured only once at the end of our algorithm, providing us the complete phase.

Going past the differences between IQPE and basic QPE, let us flesh out some details which are important to be dealt with before moving on to the implementation of our circuit.

• Since the same qubit is needed for the subsequent bit-identification steps, a ‘reset to|0⟩’ operation is mandatory. This helps us utilise the same qubit for the determination of the remaining bits in our phase.
• The last thing which we need to look at is the classically controlled rotation gates. Although we may use classically controlled rotation gates pertaining to each previously identified bit, there can be one more optimisation. When we are at the jth qubit and need an inverse rotation of

what we do is apply these rotations ‘sequentially’ (as shown in image 6). But, since we do have the values of the previous bits with us, we may construct the complete rotation and replace it with one single rotation gate. This gate would apply the equivalent rotation in the jth qubit to give us the desired single-bit phase.

In my opinion, this is a pretty cool algorithm since we just use 1 extra qubit for the determination of our phase! With all of the intuitions, mathematics, and optimisations up our sleeve let’s head over to the implementation part with IBM’s Qiskit.

IQPE Implementation

Unitary matrix

The unitary for our implementation is going to be a 2-qubit matrix made up of the X and Z gates.

State preparation and desired phase

Since the gate is a 2-qubit matrix, there are 4 eigenvectors, namely |1⟩|+⟩, |0⟩|+⟩, |1⟩|-⟩, |0⟩|-⟩. This implementation looks to identify the phase for the eigenvector |1⟩|+⟩. Since the unitary applied to this eigenvector generates -1 as an eigenvalue, we should expect the algorithm to identify the phase as 1/2 (work out the mathematics and you’ll be able to figure out why it is 1/2).

Optimised IQPE circuit

Results for estimation

Plot for estimation of single-qubit unitary

Let us see the performance of our algorithm for a one-qubit phase unitary with phase = 1/6. This plot shows us the behavior of the algorithm as the number of iterations increases and we can clearly see that the algorithm is convergent to the actual phase as the number of iterations increases beyond 4.

That’s it, that’s IQPE folks!

Coming to the end of this post, I would like you to again first remember the intuitions and the ideas which led to the optimisation of the basic QPE algorithm, and once you are familiar with what the algorithm means, have a look at the mathematics. Hope you learned some new concepts here and enjoyed reading it as much as I did writing it. As always, stay tuned for more by Quantum Untangled!

Code used in the above article can be found in this repository.

Iterative Quantum Phase Estimation — QPE algorithms was originally published in Quantum Untangled on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last post of our series, we explored some of the required mathematics to tackle phase estimation. We learned phase kickbacks and phase encodings. This post revolves around the last piece of our puzzle (QPE), i.e., the Quantum Fourier Transform followed by the combination of all the mathematics into the QPE algorithm and why do we even care about it in the first place. Let’s get started then.

Quantum Fourier Transform

Sounds a bit scary.

Anyway, let’s remember where we left off in the previous post. This image would help you in recalling the final quantum states that we had in the qubits:

We concluded with the remark that phase was being encoded up to different bits in our ancilla register but we still needed a ‘way’ to extract those bits out. Quantum Fourier Transform(QFT) is how we do it.

Although many people teach QFT in a conventional way, saying that it is a change of basis(which it is) and then write the resultant state for a given binary state. We are not going to do that. Here, we are going to first build up the inverse circuit (QFT⁻¹) from scratch, look at its use case in the QPE algorithm and when we are comfortable with it, we just take the complex conjugate of the circuit that we have built.

Let us start from the simplest of cases. By simple, what I mean to say is that let us take the qubit which only has 1 bit of information encoded in its phase. Which bit is that? If we see closely, Q(n-1) contains only a single bit, θₙ encoded in its phase:

This is the last bit in our ancilla register. How do we extract it? Let’s try out some mathematics. Expanding our state when θₙ = 0 and θₙ = 1 gives us:

This is a very important representation of our state. This means that whenever the value of θₙ is 0 or 1, our final state is going to be|+⟩ and |-⟩ respectively. This is exciting because |+⟩ corresponds to |0⟩ and |-⟩ corresponds to |1⟩ if we measure in the X-basis! Thus, if we apply an H-gate on this ancilla qubit, we are going to measure the qubit either as 0 with probability 1 or 1 with probability 1.

Now think of this — if we have some means to transform each of the states Qi to the states |+⟩ or |-⟩(the X basis), we could measure them in the X basis and extract the information stored inside their phases, one bit at a time. Let us look at the math to drive home this simple discovery —

This is the basic idea behind QFT⁻¹ that we are trying to build — somehow extract the bit information from our qubits by changing the basis. Note that we are still building upon intuition and thus, we don’t have any concrete formula for it, yet.

If you understood the workings till now, let’s move on to the next qubit.

Well, there isn’t just 1 bit in our phase encoding — there are 2. What if there was just 1? Could it be somehow reduced to that simpler case? You should remember one thing though — we have the final state of θₙ with us. Since we proved in image 5 that θₙ either collapses deterministically to 0 or 1, this also means that the previous bit was either in the state |0⟩ or in the state |1⟩ just before the collapse.

Let us have a closer look at the phase of the second last qubit.

Well, you see that if θₙ is 0, there shouldn’t be any trouble — we just measure in the X basis again and get the answer for the next bit. But if θₙ is 1, the phase needs to be reduced to a simpler version through which we can extract the next bit. If you think about it, doesn’t this sound like a conditional gate? If we have θₙ as 0, don’t do anything, if θₙ is 1 do something to simplify the phase. What is this something?

As we saw in image 7, the phase consists of contributions from both the current and the last bit. The phase contributed by the last bit θₙ can be turned off using a controlled rotation gate conditioned on the state of θₙ bit. This means if θₙ = 0, no gate is applied to the target qubit. If θₙ was 1, apply a rotation to cancel out the θₙ/2² term from our phase. What should the rotation be? It is exactly equal to —

Let us see the simple circuit which is used to accomplish this and what is the final state —

This is the heart of this transformation — we want to cancel out all the bits other than the one we want to find and then collapse the qubit to determine the bit information. Given that we have understood intuition till now, let’s look at the general case.

Let us say we have a phase, encoded as —

and we want to determine θⱼ. If we are able to cancel out the bits —

with the inverse rotation —

we would be left with phase 0.θⱼ which allows us to determine θⱼ with very high certainty. This brings us to our controlled inverse rotation gate — a gate that is conditioned on a single control qubit and applies the needed inverse rotations in our current qubit:

Since the trailing bits, i.e.,

would be identified by us as either |0⟩ or |1⟩ in earlier trials, we have the ability to apply the correct C-ROTₖ gates to turn off the kᵗʰ bit of our representation. To be clear, k is the position of the bit, from the decimal point, that we want to cancel out. For example, if the phase encoding is 0.001 and we want to cancel out the last bit(3rd from the decimal point), the C-ROT₃ gate, conditioned on the last bit state, would be applied.

Taking another example, let us say we wanted to determine the second last bit in our phase. Let us assume the phase encoding is something like 0.01. Now, to cancel out the θₙ(last bit) we would apply the C-ROT₂ gate conditioned on θₙ (as θₙ is the second bit to the right from the decimal point). The circuit we would be getting would be is exactly the same as we saw in image 9 with the change that the controlled gate, now, has a name —

We have come a long way but I am sure that you have now understood what actually happens in the QFT⁻¹ circuit and are able to make sense of and thus appreciate the final circuit. Again, we have built QFT⁻¹ without any kind of pre-defined formula and maybe you could even build the formula by yourself!

Basic QPE with qiskit

OKAY. With all the math under our belt now, let us see the complete Phase Estimation circuit with all our components. We’ll be doing some hands-on phase estimation using IBM’s qiskit package and constructing our circuit piece by piece. The phase we are trying to estimate is 1/8 and we have a 1-qubit unitary. Since phase 1/8 is represented as 0.001 in binary, we will be using 3 extra qubits for phase encoding, one for each bit.

• Preparation of Eigenvector

• Phase Encoding

• QFT⁻¹ circuit

• Final Circuit in Qiskit

• Results for estimation using a single qubit phase gate with θ = 1/8

Applications of QPE

The Quantum Phase Estimation algorithm is used as a sub-routine in many other quantum algorithms like Shor’s factoring algorithm (the most famous) and Quantum Amplitude Estimation algorithms. Another major application for QPE is eigenvalue estimation for quantum systems. Since atoms and molecules follow unitary evolution, the observable values of their hamiltonians are their eigenvalues, and using QPE, we could also estimate the energy eigenvalues of a molecule.

Coming to the end of this article, I would like you to take a step back from all the math and first intuitively think of the phase estimation algorithm, what it does, how can it be implemented, what are its limitations. Then when you are comfortable, the math should be worked out completely to get the final grasp. While we haven’t discussed what happens when the phase does not have an exact binary representation, we shall in the upcoming posts. I hope you liked the ideas and concepts behind Phase Estimation Algorithm and learned some new things here and there.

Stick around for more by Quantum Untangled.

You may find the code in this repository.

Quantum Fourier Transform and Basic QPE — QPE algorithms was originally published in Quantum Untangled on Medium, where people are continuing the conversation by highlighting and responding to this story.