SofTeCode Blogs

One Place for all Tech News and Support

Directions for Quantum Algorithms & Applications in Qiskit

10 min read

What does it mean to be an honest library for Quantum Algorithms & Applications (QA&A) research in 2020? this is often a really difficult question that we’ve discussed extensively within the IBM Quantum team. It likely isn’t a raw performance in running applications, because the classical software packages which are optimized for many years, like CPLEX or Gaussian, will leave us within the dust for quite a while. In fact, we frequently consider the “incumbent” libraries for Quantum Algorithms to be NumPy and MATLAB, because most researchers know them and that they perform matrix operation quite well. It likely isn’t the sheer number of algorithms implemented during a library either, as any library can simply wrap tons 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 nobody algorithm is practically useful.
Three Big Ideas In Quantum Algorithms Software

There’s a crucial idea about QA&A software that we’ve identified in our extensive discussions with users. By way of analogy, many QA&A libraries immediately provide “action figures,” albeit there are not any particularly compelling characters yet when most users want to tend toy bricks. What this suggests is that providing quantum algorithms which run quickly is just not enough to be compelling immediately, because none of those algorithms are useful to anyone, and certainly are a far stretch from the algorithms which can 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 in the least – could also be more compelling. this is often the thought of providing primitives, not black boxes.

Central to the present idea is that the notion that the primitives are easy to know, which ties into another major theme and challenge of excellent QA&A software. “Easy to understand” depends entirely on the user’s background, and we’re building for a userbase of a minimum of 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 alleged to build software which appeals to every one of their individual strengths, industry conventions, preferred software abstractions, and language? If we are saying “we’ll just stick with QA&A language and abstractions,” we risk alienating virtually everyone. for instance, 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 don’t want to be confined to their “entry point” – it’s typical to ascertain a chemist venturing into Quantum Machine Learning, or a programmer venturing into Quantum Chemistry. And even crazier, these people want to speak and work together! this concept of being a Rosetta stone for the QA&A community is clearly vital.

Maybe the foremost important “language disconnect” immediately is between the software engineers and therefore the quantum information theorists. As a QA&A library, appealing to each side is an incredibly challenging bridge to cross, including helping this example. Is it even possible to make sure that the theorists are speaking valid code, and therefore the software engineers are speaking valid physics? Over a previous couple of years, we’ve spotted an opportunity: Often we discover that both of those sides plan to study the opposite by digging into the software. What better thanks to studying Shor’s algorithm as a programmer than to step through the code, or to find out about the implementation as a theorist doing the same?

For this to figure, there clearly can’t be any black boxes, but even the primitives must be explorable. There can never be A level within the software where we are saying “sorry, don’t come down here, it’s hacky and not for you to know .” Everything must be clean code and according to physical formalism. We call this concept having no bottom point within the code.

A New Direction In QA&A Software

Today marks the discharge of three major progress 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 his or her practical applications and/or complexity-theoretic properties.

Second, we’ve introduced the Optimization module (source, documentation), a library for researchers and beginners alike to interact 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 those releases represents an enormous new direction in QA&A software and can be introduced in additional detail over the approaching weeks.
The Circuit Library

We’ve begun a serious new exploration and area within Qiskit’s evolution: a collaborative library for the gathering, cataloging, and use of interesting quantum circuits. Interesting can mean many things, be it algorithmic importance, like the Quantum Fourier Transform or Arithmetic circuits, complexity-theoretic importance, like the Quantum Volume, Hidden Linear Function, and Correlation circuits, or applications importance, like data preparation circuits. For now, we’ve initiated the library with a couple of families of circuits, including some which represent generalizations and expansions of popular circuits for quantum algorithms. you’ll already begin to check these circuits in Qiskit’s algorithms today, most of which are changed to use the circuit library by default. But this is often only the start of this story – we glance forward to active contribution and community discussion during this exciting new area of activity.

The Optimization Module

Qiskit’s new Optimization module may be a collection of tools for first-class Quantum Combinatorial Optimization research. it’s 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 function 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 within the Optimization module is often constructed using complex, 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 simply solve their problem with CPLEX for comparison to quantum algorithms.

If researchers want to dig further, they will see that to deal with their problem with a Quantum algorithm, it can either be translated into an Oracle for a solution by a Grover-based method or into an Ising Hamiltonian for a solution by an Eigensolution-based method. they will then see that VQE, QAOA, and QPE are all MinimumEigensolvers, and maybe wont to address the Ising Hamiltonian, then on down into the code. But they will also see that ADMM within the Optimization module may be a higher-order method to unravel their problem, employing 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 form the foremost of an upscale set of tools within the module itself. The Optimization Module is intentionally within the same GitHub repository alongside the core algorithms modules, to form 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 serious new direction in two ways:

First, going forward, the Optimization module will still be expanded by a really active group of Optimization researchers at IBM, and you ought to expect to ascertain vigorous development and community activity around it.

Second, and more broadly, you’ll notice that the optimization directory within the ASCII text file is flanked by three other directories: chemistry, finance, and machine learning, and shortly also physics. Over the subsequent several months, you ought to expect to ascertain announcements in each of those areas with an identical design focus because of 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 start the method of build-up these modules. The chemistry module (source, documentation) already includes powerful tools for computing Molecule Ground States and the Excited States today, but you’ll also expect to ascertain a big expansion there over the approaching 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 whole interface and execution engine of the repository.

The Operator Flow

When brooding about finding a language of both QA&A theory and implementation, it’s hard to invite a greater gift than the Operator formalism. Operators are already the language of not only quantum algorithms theory, but nearly all of physics. All of the formalism’s guts are concepts of functions, ideas every programmer knows as a habit . they’re 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’re perfect.

In this release, we strove to be faithful having no bottom point that users couldn’t dig past and understand, and saw the Operators because the system that we will use to offer quantum algorithmic building blocks to both the engineers and theorists. Operators have always been the computational backbone of Aqua, supporting most of the essential algorithmic primitives we deem granted. At one point there was one 3000+ line Operator class powering VQE, QAOA, QPE, and lots of other things. But these were built as a bit of infrastructure, not for end-users to probe, use, and explore. There was also some overlap with Terra’s Operators, which we knew we could use as computational primitives instead of duplicate.

In this release, we introduced the operator flow (source, documentation), a system for constructing complex strings of quantum and classical computation, all counting on a strict and intuitive physical formalism (much of which was inspired by John Watrous’s the idea of Quantum Information) and backed by Terra’s computational primitives. Algorithms are now built out of the simple 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. quite anything, we strove to create a system that we ourselves would default to for all of our research needs (even over NumPy), and therefore the result’s fundamentally designed for research play. Note however that this release represents the v0 for the operator flow, and there are more additions to be made.

The Polaris of the operator flow is to function the ultimate link within the linguistic bridge between the idea and implementation of QA&A. the principles of the Operator formalism are built into the code therefore the software engineers are learning the formalism incidentally as they learn the code, and speaking their implementations in Qiskit will mean speaking invalid physics. Similarly, the formalism aims to ask theorists to encode their theoretical ideas into the system, so once they discuss their algorithms in Qiskit language, it also represents valid implementation.

The Algorithms Interfaces

Another major change you’ll immediately notice about the ASCII text file is that the reorganization and refactoring of the algorithms directory (source, documentation) (not to stress, we didn’t break your imports). We’ve divided the algorithms up into directories and interface base classes by computational purpose in order that they are often passed and interchanged within other algorithms with an easy and clear contract. for instance, ADMM within the Optimization module can accept a MinimumEigensolver algorithm to be used as a subroutine. this concept 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 had been an initial comfort for brand spanking, 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 attention on research play over black-box execution meant this is able to be too expensive to take care of within the grander mission, and that we felt that forcing users into the code may be a new necessity for fulfillment using Qiskit’s algorithms.
Native Circuits

If you’re conversant in the algorithms, you’ll also find that the QuantumCircuit primitives you’ll use within the algorithms are significantly blown bent accommodate and encourage the utilization of arbitrary circuits. Whereas previously a knowledge feature map circuit within the Quantum Support Vector Machine algorithm or a wavefunction ansatz circuit within the Variational Quantum Eigensolver might require some real effort to vary or customize, all of the algorithms in Qiskit now accept arbitrary parameterized circuits directly. this is often an attempt to bring QuantumCircuits more to the forefront and consciousness of algorithmic execution, and support them as first-class citizens. Further, it had been stepped 0 in introducing the circuit library.
Looking Ahead

These new directions for Quantum Algorithms & Applications in Qiskit are off and running. we have a lively and passionate development team who have an interest in rethinking abstractions and building blocks of all types. we would like to listen to your opinions and wild ideas for a way to form Quantum Algorithms & Applications research even more fun in Qiskit.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

Give your views

This site uses Akismet to reduce spam. Learn how your comment data is processed.