May 1, 2020 | Written by: Donny Greenberg and Stefan Wörner
Categorized: Quantum Computing
Share this post:
What does it mean to be a good library for Quantum Algorithms & Applications (QA&A) research in 2020? This is a very difficult question that we’ve discussed extensively within the IBM Quantum team. It likely is not raw performance in running applications, as the classical software packages which have been optimized for decades, like CPLEX or Gaussian, will leave us in the dust for quite some time. In fact, we often consider the “incumbent” libraries for Quantum Algorithms to be NumPy and MATLAB, because most researchers know them and they perform matrix multiplication quite well. It likely is not the sheer number of algorithms implemented in a library either, as any library can simply wrap a lot of hacky algorithm code in API calls, but we’ve found that users can’t do anything with such black boxes in an era when no one algorithm is practically useful.
Three Big Ideas In Quantum Algorithms Software
There’s an important idea about QA&A software that we’ve identified in our extensive discussions with users. By way of analogy, many QA&A libraries right now provide “action figures,” even though there are no particularly compelling characters yet, when most users want to be given toy bricks. What this means is that providing quantum algorithms which run quickly is simply not enough to be compelling right now, because none of these algorithms are useful to anyone, and likely are a far stretch from the algorithms which will ultimately provide Quantum Advantage. Users care about rapidly building and experimenting with new algorithms, and arguably a library with extremely strong algorithmic building blocks – even one with no black-box algorithms at all – may be more compelling. This is the idea of providing primitives, not black boxes.
Central to this idea is the notion that the primitives are easy to understand, which ties into another major theme and challenge of good QA&A software. “Easy to understand” depends entirely on the user’s background, and we’re building for a userbase of at least eight different backgrounds:
- Total QA&A beginners (e.g. people learning from a textbook)
- Experienced Quantum Information Theorists
- QA&A-interested Software Engineers
- QA&A-interested Quantum Chemists
- QA&A-interested Optimization researchers
- QA&A-interested Finance researchers
- QA&A-interested Physics (e.g. condensed matter) researchers
- QA&A-interested Machine Learning researchers
How are we supposed to build software which appeals to each of their individual strengths, industry conventions, preferred software abstractions, and language? If we say “we’ll just stick to QA&A language and abstractions,” we risk alienating virtually everyone. For example, we’ve found that forcing the Optimization crowd to only work with Ising Hamiltonians to represent their familiar Quadratic Optimization problem is painful and breaks their intuition. And researchers do not want to be confined to their “entry point” – it is typical to see a chemist venturing into Quantum Machine Learning, or a software engineer venturing into Quantum Chemistry. And even crazier, these people want to talk and work together! This idea of being a Rosetta Stone for the QA&A community is clearly very important.
Maybe the most important “language disconnect” right now is between the software engineers and the quantum information theorists. As a QA&A library, appealing to both sides is an incredibly challenging bridge to cross, let alone helping this situation. Is it even possible to ensure that the theorists are speaking valid code, and the software engineers are speaking valid physics? Over the last few years, we’ve spotted an opportunity: Often we find that both of these sides attempt to learn about the other by digging into the software. What better way to learn about Shor’s algorithm as a software engineer than to step through the code, or to learn about the implementation as a theorist doing the same?
For this to work, there clearly cannot be any black boxes, but even the primitives must be explorable. There can never be a level in the software where we say “sorry, don’t come down here, it’s hacky and not for you to understand.” Everything must be clean code and consistent with physical formalism. We call this idea having no bottom point in the code.
A New Direction In QA&A Software
Today marks the release of three major steps forward in Qiskit’s Quantum Algorithms & Applications toolset.
First, we’ve introduced the circuit library (source, documentation) into Qiskit Terra, providing feature-enhanced families of circuits which are interesting for their practical applications and/or complexity theoretic properties.
Second, we’ve introduced the Optimization module (source, documentation), a library for researchers and beginners alike to engage in cutting-edge development and experimentation in Quantum Combinatorial Optimization.
Third, we’ve rebuilt Qiskit’s core algorithmic tools (source, documentation) to optimize them for research and prototyping, including a brand-new system for constructing quantum computational flows, a full library reorganization, the introduction of hierarchical algorithms, and deeper support for quantum circuits as first-class primitives.
Each of these releases represents a big new direction in QA&A software and will be introduced in more detail over the coming weeks.
The Circuit Library
We’ve kicked off a major new exploration and area within Qiskit’s evolution: a collaborative library for the collection, cataloguing, and use of interesting quantum circuits. Interesting can mean many things, be it algorithmic importance, such as the Quantum Fourier Transform or Arithmetic circuits, complexity theoretic importance, such as the Quantum Volume, Hidden Linear Function, and Forrelation circuits, or applications importance, such as data preparation circuits. For now, we’ve initiated the library with a few families of circuits, including some which represent generalizations and expansions of popular circuits for quantum algorithms. You can already begin to test these circuits in Qiskit’s algorithms today, most of which have been changed to use the circuit library by default. But this is only the beginning of this story – we look forward to active contribution and community discussion in this exciting new area of activity.
The Optimization Module
Qiskit’s new Optimization module is a collection of tools for first-class Quantum Combinatorial Optimization research. It is built on top of all the familiar Qiskit primitives, but with the Optimization community’s conventions and formalism in mind. The core idea here is for the module to serve as a native toolset for Optimization researchers, written in their language and interoperable with their standard software, but also serving as an entry point and guided translation into the deeper structures of Qiskit.
For example, the core problem representation in the Optimization module can be constructed using docplex, an industry standard for Optimization development and research. This has numerous benefits for the comfort and approachability of the library, but also practically allows researchers to easily solve their problem with CPLEX for comparison to quantum algorithms.
If researchers want to dig further, they can see that to address their problem with a Quantum algorithm, it can either be translated into an Oracle for solution by a Grover-based method, or into an Ising Hamiltonian for solution by an Eigensolution-based method. They can then see that VQE, QAOA, and QPE are all MinimumEigensolvers, and can be used to address the Ising Hamiltonian, and so on down into the code. But they can also see that ADMM in the Optimization module is a higher-order method to solve their problem, using a MinimumEigensolver as a subroutine, opening other interesting doors of exploration.
This is all intentionally legible and explicit. The user can venture as far down or up as she chooses to make the most of a rich set of tools within the module itself. The Optimization module is intentionally in the same github repository alongside the core algorithms modules, to make traversing that wall easy and natural, both in exploration and contribution. One can see here the ideas of providing primitives and a Rosetta Stone strongly motivating our design.
The Qiskit Applications Modules
The Optimization module is the beginning of a major new direction in two ways:
First, going forward, the Optimization module will continue to be expanded by a very active group of Optimization researchers at IBM, and you should expect to see vigorous development and community activity around it.
Second, and more broadly, you may notice that the optimization directory in the source code is flanked by three other directories: chemistry, finance, and machine learning, and soon also physics. Over the next several months, you should expect to see announcements in each of these areas with a similar design focus as the Optimization module.
With the exception of chemistry, these directories are only stubs today, as we’ve moved the relevant code out of the core algorithmic areas to begin the process of building up these modules. The chemistry module (source, documentation) already includes powerful tools for computing Molecule Ground States and Excited States today, but you can also expect to see a significant expansion there over the coming months.
The Operator Flow, Algorithms Interfaces, and Native Circuits
The Aqua 0.7 release was a doozy. We collected input from dozens of users, set an aggressive course, and basically rewrote the entire interface and execution engine of the repository.
The Operator Flow
When thinking about finding a language of both QA&A theory and implementation, it’s hard to ask for a greater gift than the Operator formalism. Operators are already the language of not only quantum algorithms theory, but nearly all of quantum physics. All of the formalism’s guts are concepts of functions, ideas every software engineer knows as second nature. They are extremely compact and recursive, describing complete quantum computations in papers often in single lines. And almost every beginner to quantum computing meets them as gates on their first day. As a universal language between theorists and software engineers, they are perfect.
In this release, we strove to be true to having no bottom point that users couldn’t dig past and understand, and saw the Operators as the system that we can use to give quantum algorithmic building blocks to both the engineers and theorists. Operators have always been the computational backbone of Aqua, supporting most of the basic algorithmic primitives we take for granted. At one point there was one 3000+ line Operator class powering VQE, QAOA, QPE, and many other things. But these were built as a piece of infrastructure, not for end users to dig into, use, and explore. There was also some overlap with Terra’s Operators, which we knew we could use as computational primitives rather than duplicate.
In this release we introduced the operator flow (source, documentation), a system for constructing complex strings of quantum and classical computation, all relying on a strict and intuitive physical formalism (much of which was inspired by John Watrous’s The Theory of Quantum Information) and backed by Terra’s computational primitives. Algorithms are now built out of the straightforward gluing together of operators, state functions, and measurements, all carefully designed to represent Physical and computational concepts equally and accurately. The system is optimized for rapid prototyping and syntactic power, easy object introspection, and clarity of algorithmic flow. More than anything, we strove to build a system that we ourselves would default to for all of our research needs (even over NumPy), and the result is fundamentally designed for research play. Note however that this release represents the v0 for the operator flow, and there are many more additions to be made.
The North Star of the operator flow is to serve as the final link in the linguistic bridge between the theory and implementation of QA&A. The rules of the Operator formalism are built into the code so the software engineers are learning the formalism incidentally as they learn the code, and speaking their implementations in Qiskit will mean speaking in valid physics. Similarly, the formalism aims to invite theorists to encode their theoretical ideas into the system, so when they discuss their algorithms in Qiskit language, it also represents valid implementation.
The Algorithms Interfaces
Another major change you may immediately notice about the source code is the reorganization and refactoring of the algorithms directory (source, documentation) (not to worry, we didn’t break your imports). We’ve divided the algorithms up into directories and interface base classes by computational purpose so they can be passed and interchanged within other algorithms with a simple and clear contract. For example, ADMM in the Optimization module can accept a MinimumEigensolver algorithm to be used as a subroutine. This idea of allowing algorithms to serve both as applications and as computational subroutines is critical to allowing the library to be used as building blocks.
You may notice the removal of the JSON-based declarative interface for specifying algorithm executions. We found through many user discussions that while it was an initial comfort for new users testing out the code, this interface didn’t introduce users to the objects within the code or reveal its extension points and execution flow. Shifting to a focus on research play over black-box execution meant this would be too expensive to maintain in the grander mission, and we felt that forcing users into the code is a new necessity for success using Qiskit’s algorithms.
If you’re familiar with the algorithms, you’ll also find that the QuantumCircuit primitives you can use in the algorithms have been significantly blown out to accommodate and encourage the use of arbitrary circuits. Whereas previously a data feature map circuit in the Quantum Support Vector Machine algorithm or a wavefunction ansatz circuit in the Variational Quantum Eigensolver might require some real elbow grease to change or customize, all of the algorithms in Qiskit now accept arbitrary parameterized circuits directly. This is an effort to bring QuantumCircuits more to the forefront and consciousness of algorithmic execution, and support them as first-class citizens. Further, it was step 0 in introducing the circuit library.
These new directions for Quantum Algorithms & Applications in Qiskit are off and running. We have an active and passionate development team who are interested in rethinking abstractions and building blocks of all kinds. We want to hear your opinions and wild ideas for how to make Quantum Algorithms & Applications research even more fun in Qiskit.
We want to express our sincere gratitude to the people who worked tirelessly to make this release happen (in alphabetical order): Panagiotis Barkoutsos, Andrew Cross, Anton Dekusar, Julien Gacon, Claudio Gambella, Jay Gambetta, Austin Gilliam, Constantin Gonciulea, John Gunnels, Takashi Imamichi, Ali Javadi-Abhari, Kevin Krsulich, Jakub Mareček, Manoel Marques, Dmitri Maslov, Atsushi Matsuo, John Smolin, Andrea Simonetto, Kristan Temme, Matthew Treinish, Chris Wood, and Steve Wood.
Quantum starts here