Musty Thoughts

Quantum Software Newsletter

Thu, 12 Jun 2025 04:30:00 +0000

Dear Reader,

Today, together with my friend Konrad, we’re launching a newsletter about developing quantum software. In this post I want to tell you a bit more about this project. If you don’t want to learn more and just want to subscribe, click here.

Context

First, let me tell you about Konrad.

Konrad is a friend of mine – we’ve been working together since my first quantum job at Bohr in 2018, then Zapata and now at PsiQuantum. So we’ve been working together for ~7 years, with some brief breaks. He’s an absolute beast, I haven’t met anyone¹ in my career who came close to the level of proficiency in programming, especially in Python. I have learned soooo much from him over the years and always enjoyed our collaboration.

At some point we decided that it would be nice to share some of the experience we have with other people in the community. It seemed to us that newsletter will be a good form for that:

A lot of the things we want to write about are relatively short tips, so newsletter’s short form seems appropriate.
We’ve been subscribed to some educational newsletter in the past and it’s a decent format for learning
It’s the kind of public committment that will probably force us to do it regularly.

So after waaaay too long period of “We’re busy now, let’s start working on it next week”, we’re finally launching it!

Who is this for?

We want this newsletter to be useful for anyone working with software in the quantum computing space. We’re thinking about two main groups:

Researchers – they often have no real training in software engineering, but work with software every day. From our observations, they often require just a little nudge here and there to make their life much easier.
Software Engineers – people who are in the same boat as we are! We all work on different projects, but the problems are often very similar, so we hope our perspective might shed some new light at them.

However, software is software. There’s not that many problems that are specific to quantum computing, so it will be most likely widely applicable to anyone working with scientific software in general.

What to expect?

We will be sending you one e-mail per week. Some of the topics that we have already written up or plan to do so are:

Testing complex algorithms
Pros and cons of using jupyter notebooks
Basic debugging techniques
Profiling code
Managing virtual environments

But we’ll also share some new tools that we just discovered or write about some ad-hoc cases that we have encountered in our daily work.

What’s next?

You can find a landing page & subscription form here!

Also, at IEEE Quantum Week conference we’ll be hosting a tutorial called “10 things ruining code in your research project – do this instead!”, it’ll be on Tuesday, September 2nd. If the premise of the newsletter looks interesting to you, I’m sure this tutorial will also be!

Have a great day!

Michał

Footnotes:

Except our friend Alex, who’s also S-tier. Hi Alex! ↩

IEEE Quantum Week 2024

Mon, 14 Oct 2024 10:30:00 +0000

Dear Reader,

I’m writing this while sitting on the train from Montreal to Toronto. Why did I visit Montreal?

To attend IEEE Quantum Week 2024, also known as QCE24!

This was my 3rd Quantum Week and I was looking forward to it! It’s a big conference (~1500 participants) with up to 14 tracks happening simultaneously. So obviously I couldn’t keep track of everything that was going on and my perspective is biased, but I hope this will be useful for some people nonetheless. So here are some of my main takeaways from the conference.

Need for better abstraction hierarchy

Given that we’ve recently published a paper about abstraction hierarchy that I was presenting at the conference, I’ve been vigilant about the topic. However, the need for better abstraction layers and separation of concerns in quantum software was a common theme in many sessions I attended:

Quantum Algorithm Design Automation Workshops
Keynote by Jay Gambetta
Workshop on Intermediate Representations
Munich QS Software Stack Workshop
Keynote by Margaret Martonosi

I’ll write more about our paper and this problem in general in a separate blogpost, so here I’m just mentioning it as it’s clearly becoming an important topic in the community.

Standardization

Another important topic that was coming up over and over in many sessions and discussions was standardization. This allowed me to learn more about it and refine my view.

There are basically two positions in the community, which seem to be at odds with each other.

Some people say that it’s too early to standardize. We are still experimenting with many different conventions, abstractions, formats and in general ways to write software for quantum computers. The hardware landscape also changes very quickly. If we try to standardize too early, we’ll stifle the progress and we increase the risk of some nasty technology lock-in.

On the other hand, other people say that it’s really hard to collaborate and make progress. Everyone’s software is special in its own way, people are using competing conventions. Even if someone else solved your problem, then they most likely use a different format and different toolset and it might be faster to reproduce their code rather than to integrate with it.

However, after talking with various people it turns out that these two positions can be reconciled. You see, the problem is the word “standard”. When most people hear “standard”, they think “IEEE-level standard, that will take a whole committee and a thousand meetings over 3 years to come up with”. That’s also what I was thinking, but I changed my perspective after I talked with someone from NIST (which is an organization that surely treats standards seriously). She said that “standards” are basically just “agreements” and it’s all about people reaching a consensus rather than necessarily going through a formal committee. Sure, the formal standards also have their place, but in some cases, they’re an overkill.

So if instead of saying “We need standardization” we would start saying “As a community we need to agree on certain things, such as conventions and dataformats”, then I think this is a very different discussion, where we could get many more people on board. I like to use the word “community standard” for such agreements to indicate their informal character.

I’ve been working on such a “community standard” for the format to write fault-tolerant quantum algorithms for resource estimation. If this is something of interest to you, please reach out to me at mstechly@psiquantum.com!

Darpa QB program

In the past, I was involved in DARPA’s Quantum Benchmarking program. For those who don’t know about it, the goal of the program is to do a rigorous search for promising applications of fault-tolerant quantum computers and estimate the resources needed to run them when we finally have these machines. I see this program as pivotal for accelerating the progress in the field as well as guiding policymakers. For me personally, participation in this program has been one of the greatest professional experiences I had.

Therefore, it was a pleasure to see either the program itself (or the research coming out of it) mentioned several times across the conference! For those of you who’re not familiar with it, you can find more information, including the papers and tools that are output of the program here.

QRE workshops

One of the events I’ve organized was a workshop focused on Quantum Resource Estimation. I won’t write a detailed summary similarly as I did last year, so here’s a quick recap.

We had three sessions.

In the “Tools and Methods” session Mariia Mykhailova from Microsoft gave an overview of Azure Quantum Resource Estimator. It was cool to see how this tool became more extensible in the last year. In particular, Mariia showed an example of doing resource estimation for the hardware by Alice & Bob.

Then Arianna Van de Griend presented work by Alexandru Paler and Ioanna Moflic (who unfortunately couldn’t join) about the compilation of really large circuits. Representing circuits as tables in the PostgreSQL database? Wow, this was something new for me!

Lastly, Murphy Niu from UC Santa Barbara presented her work with Daniel Bochen Tan and Craig Gidney on the compilation of lattice surgery operations (e.g. those described in Game of Surface Codes). They took those operations, translated them into the “crazy pipeline diagrams from Craig Gidney’s papers” and then optimized them. Impressive!

Then we had an “Applications and Algorithms” session, where we had:

Sophia Simon (University of Toronto): “Superpolynomial improvement in precision for quantum simulations of coupled quantum-classical dynamics”
Fionn Malone (Google): “Resource estimation for the quantum computation of stopping power”
Amara Katabarwa (Zapata): “Feasibility of accelerating incompressible computational fluid dynamics simulations with fault-tolerant quantum computers”.

I think an important part of these talks was in 2 out of 3 talks, the authors relied heavily on the software tools to perform resource estimation, and not just mathematical analysis. This is important since the constant factors can sometimes be much more important than the theoretical scaling. Actually, Eleanor Rieffel (NASA) made a good comment on this in her keynote – for one algorithm she worked on, the scaling is better, but the threshold for utilizing this gain is $n=10^{18}$ !

Lastly, we had a presentation of the projects coming from the QRE Challenge that we had organized prior to the workshops by Petra Brčić and Walden Killick. And then a panel with:

Matt Harrigan (Google)
Antonio Corcoles (IBM)
Athena Caesura (PsiQuantum)
Neil Gillespie (Riverlane)

lead by Kevin Obenland (MIT LL)

Some highlights from the panel:

Making tools amenable to different computational models would be really important. For example, there are cases where counting Clifford operations is important and some, where they aren’t.
Our tools need to be able to make use of algorithm structure and not just work on bare circuits.
The QRE tools will keep evolving as we get closer to the actual working machine. It’s ok for them to be somewhat rough today, as before we get to the FT computer, a lot of the methods and assumptions will change.
In order to make sure that people who are not QC domain experts will not get scared of the outrageous numbers that we produce today, we should accompany them with a clear plan on what we plan to do to bring them down.
What we have now can be treated as 1st generation QRE tools, now we see that we’re slowly getting into 2nd generation. Maybe it’s somewhat trivial to say this, but it is a useful framing for me.

How to make things happen

One of the complaints I heard was that there was a lot of NISQ-related activity at the conference and not enough FTQC-related. Indeed – quickly scanning the list of workshops, I found only 3 out of 36 workshops, which were specifically focused on FTQC-related topics: one on Quantum Error Correction (QEC), one on decoding and ours on QRE.

However, this conference is a community effort. If you think a particular topic is important and underrepresented, please propose a session on the topic! It can be a workshop, panel, birds of feather session or something else.

Since I’ve been involved in organizing a few of these already, I could write a blogpost that explains how to approach it – if this would be useful to people, please let me know, either through a comment or e-mail!

Closing

These are some of my main takeaways. I hope this has been an interesting perspective for you. If so, please leave a comment or let me know, cause if no one reads it, I won’t be writing another one next year :)

Have a great day!

Michał

QRE workshops summary

Fri, 12 Jan 2024 10:30:00 +0000

Dear Reader,

together with a group of people (see at the end) we have organized workshops about Quantum Resource Estimation at IEEE Quantum Week 2023 in Seattle. We had a set of amazing speakers who talked about the topic from various perspectives and in this post, I would like to summarize their talks.

We have grouped the workshop into three sessions:

Grand Challenges
Machinery
Tools demonstrations

While writing this post I realized the style of each section is a bit inconsistent. That’s because the talks had different formats, so in some cases it felt more appropriate to follow the narrative of the talk closely, in other just provide a summary of their points. Hope it works well :)

As it took me long to write this blog post, I didn’t want to delay publishing it, so I have not asked any of the speakers to authorize the text! I hope I have not misrepresented anything, but if something seems suspicious, this might be the reason why.

Ok, let’s dive in!

Grand Challenges

Travis Humble

Travis Humble – director of Quantum Science Center at Oak Ridge National Laboratory.

Travis started from talking about four characteristics of quantum computers:

Area: footprint of the algorithm, in the circuit model that would be depth * width.
Error: drives how well the machine can operate and how much overhead is needed for error mitigation/correction.
Latency: not a bottleneck right now, but might be important in the future. I think it could be related to the reaction depth problem that others mentioned in their talks.
Accuracy: being able to quantify whether the answers are accurate is an important aspect of performing resource estimates.

From the perspective of applications it’s also important to estimate what is time-to-solution and power needed to run particular program.

He also mentioned some key challenges present in quantum computing now.

Managing diversity – there are many platforms and all of them change rapidly. In the context of QRE, you need to take into account the constraints and capabilities of a particular system.
Noise and errors – error mitigation and correction consume a lot of resources. It’s interesting to see how these methods develop (e.g.: Y. Kim et al ).
Model validation – we need to make sure that the model we use (either for performing error mitigation/correction or QRE) is valid. This is not trivial, as the characteristics of the devices today can change drastically over time. (see below, it’s Fig. 1 from Zhu et al. ).
Reproducibility – given the point above, being able to reproduce any results is also not trivial and something we don’t think about enough as a community.

Travis spent significant time talking about the last one. He defined reproducibility as the ability to reproduce the results from an experiment under identical conditions (within statistical confidence).

It is a grand challenge in part because it sets expectations for behavior we really can’t meet. We can’t create identical conditions to meet the point-model estimates and we need to figure out the way to connect those point-models.

I think it’s important to talk a bit about models at this point. One of the problems with QRE is that in order to get any hardware-aware numbers, you need to have some model of the hardware that you use to produce those estimates. Therefore, your estimates will be only as good as the model you use. In this context “point-model” means “model of your hardware at a given point in time”. So my interpretation of what Travis said, is that rather than relying on point models, we need to figure out a way to build more realistic models and characterize the hardware better.

He also said that understanding how variation in hardware, different noise models, etc. influence the metrics we actually care about (accuracy and time-to-solution) will be an important task.

The whole talk focused on near-term devices, but many wondered how this maps to the FTQC regime. Travis admitted, that this might be just a phase in the development of the hardware and perhaps this problem will not exist in the FTQC regime. However, it might also be true that even with error correction models for various parts of the systems are different and unstable over time, which might affect the performance and resources needed for the calculation.

Wim van Dam

Wim van Dam – Principal Researcher at Microsoft.

This talk was based on some of the research Wim and his team did in the past. Some of it has not been yet published, I’ll link to it when it’s out. Here’s a paper he was referring to, as well as Azure Quantum Resource Estimator.

Wim started his talk strong: What’s the purpose of talking about QRE? Given how big those numbers are, is it just to get depressed?

Well – no. We should take QRE seriously right now. Why? Because they will help us find good applications for QC.

What applications are we talking about? Something that’s actually important, classically amenable, and can be solved within weeks, not years. A good rule of thumb for the target execution time is a million seconds (which is roughly 12 days). A “practical quantum solution”.

Next, Wim talked a bit about the model of the stack they’ve been using for their QRE:

Error rates per gate: $10^{-11}$ to $10^{-16}$. This implies that we need QEC.
The error correction code used is planar, but it can be either surface code or Floquet code.
Given the choice of code, you choose the type of instructions (either gate or Majorana-based) and then the type of hardware.
Stack is divided into three levels: logical qubits, QEC and physical qubits

Using this model, they’ve chosen various sets of parameters: optimistic, pessimistic and based on Majorana (if you’re not sure what that means, but there’s explanation in the paper).

After getting QREs, the problem is that some of the estimates they got take more than 2 weeks. However, having these numbers (even if they’re a bit depressing) allows us to better articulate the needs of the application.

Then they asked, whether there’s a single number, that summarizes the core strength of the hardware and they came up with rQOPS (reliable Quantum Operations Per Second):

R = Q * f at P_l
f: logical clock speed
Q: the number of reliable logical qubits
P_l: error rate of logical qubits

They have analyzed many use cases and broke them down in three categories:

First Scientific Applications: Dynamic properties of Ising models: ~kilo rQOPS at $10^{-8}$ error rate.
More Scientific Applications: Groundstate properties of Fermi-Hubbard or Heisenberg model: ~Mega rQOPS at $10^{-12}$ error rate.
Practical Chemistry Applications: Quantum chemistry with 30-40 molecular orbitals: ~Giga rQOPS at $10^{-18}$ error rate.

In the end, Wim commented that it’s important to have a link between algorithm and hardware developers: Big O notation is nice, but metrics such as rQOPS allow you to be physics-aware while being an algorithm designer. But also, they allow experimentalists to easily answer questions such as: “If I improve this aspect, what are the algorithmic consequences?”

Regardless of where you work in the stack, resource estimation is a compass that tells you what to work on.

Panel

For the panel, apart from Travis and Wim, we also had:

Oliva Crawford from Riverlane
Will Zeng from Quantonation
Dave Clader from BQP Advisors

Here are some of my favorite insights.

Question: What are the biggest challenges in QRE?

QRE is a process composed of many steps and at each step one needs to make a choice. Many of the components don’t exist yet. This makes making reasonable assumptions and approximations difficult.
Communicating the results so they are reproducible and meaningful.
Building tools is critical.
Making the optimism concrete is important.

Question: What is the right approach to attack the scalability problem?

Try to be as accurate as possible at the abstract circuit level. Ignore QEC, routing layouts, etc., just deal with the gates. This is a very useful place to start.
We can have the best QRE but there is still a question of whether this is even the right program to run. Verification is an important open problem and gets harder as the system scales.
Getting precise numbers takes time, and immediate feedback is super important. There’s a tradeoff between being precise and being fast about it.
You need to have libraries to do fixed-point arithmetics and other basic subroutines to speed up the research

Question: How to communicate very big numbers (months of runtimes, billions of T-gates) in a way that’s productive and doesn’t scare people?

We need to have metrics that we can work towards which will remain valid metrics all the way to the utility. Otherwise, from the outside, it looks like changing the goalpost.
It’s also important that people get used to those numbers. We need to make it clear that we’re a long way from the FTQC calculations.
The real value of doing concrete resource estimates is that once someone produces those resource estimates, the community jumps in and the numbers get improved. At some point we’ll hit some asymptotic barriers

Extra quotes worth mentioning:

Often we find that when you look at all the details you find out that the algorithms actually don’t give you any speedup.
Arguably this is the most important workshop of the week <3

Machinery

Sam Jacques

After a break we got into the “QRE Machinery” sessions. We started with a talk by Sam Jacques who’s Assistant Professor at the University of Waterloo.

The talk was about Sam’s experiences working on multiple projects, during his time at Microsoft, Oxford, and Waterloo. Sometimes it got pretty detailed, so rather than trying to reproduce the whole reasoning and story, I’ll just cover the main points:

A huge cost driver in Shor’s algorithm is performing arithmetics
You can either use low, assembly-level languages (like qiskit) or high-level (like Q#), but there’s nothing in between right now.
Apart from calculating resources for a particular algorithm, we also need to check for its correctness.
Fixing compilation bugs is extremely hard – Sam talked about a story of a particular bug in Q#, which took about 2 years to properly fix, as it was coming back in various flavors.
Introducing feedback loops with classical measurements leads to new level of bugs in the algorithms and compilation.
If one breaks a couple of abstraction layers and implements the algorithm at the level of surface codes, it allows for a whole new level of optimizations. However, it’s extremely tedious and manual, there are absolutely no tools to do this.
People focus too much on T-count, and in some cases, T-depth and reaction speed are the real bottlenecks.

Summary slide from Sam:

Automating resource estimations is hard
No perfect trade-off between generality and accuracy
It’s too early to pick architectures or assumptions

Sam’s QRE wishlist:

Software to work with 2D surface codes
More attention to routing and physical layout problems
Free your minds from reversible classical computation

Daniel Litinski

Daniel Litinski is a Quantum Architect at PsiQuantum.

Daniel talked about his recent paper about elliptic curves, but this paper about active volume also provides a lot of relevant background. So if you’d like to get into real technical details, that’s where you should go. Here I’ll try to get across some major points from the talk.

Daniel started from talking about the differences between “active volume (AV) architecture” and “baseline architecture”. The two main points for me:

In baseline architecture the speed of performing T gates is constant, but in AV architecture, thanks to non-local connections, speed can be increased by adding more qubits.
In the baseline architecture our primary resources are T/Toffoli gates, in AV architecture our primary resource is, well, Active Volume. The ratio for AV to Toffoli counts differs from subroutine to subroutine. In general, it’s favorable for arithmetic, but it can be quite costly for lookup tables.

After this, he talked more about various compilation optimizations for the elliptic curve algorithm. Some of them are asymptotic in nature – they come from parallelization and would not apply if we wanted to break only one key at a time.

Given that the first half of the computation will be the same for many keys, we can reuse it to break multiple keys (2x reduction).
You only need to generate 208 out of 256 bits on a quantum computer, as the other 48 can be brute-forced on a classical computer. It costs less than a million CPU hours (also see Martin Ekera’s paper).
Spread the cost of modular inversion (the most expensive operation in the algorithm) over multiple instances (~2.5 reduction).
There’s a trick called “windowing” where we precompute some values classically and put them in a lookup table, which is cheaper to implement on a QC than calculating them on the fly.

Each instance of the algorithm uses about 3k logical qubits & 100m Toffoli gates / 7b blocks of AV. But the more keys we calculate in parallel, the smaller the number of Toffoli gates per key (see tricks above). Asymptotically it gets to about 50m Toffoli gates per key (at around 50k logical qubits). To put it in context, this is a relatively small number – RSA 2048 requires over a billion Toffoli gates and FeMoCo 10 billion Toffolis.

However, it’s worth noting, that some of these tricks only make sense in AV architecture – in baseline architecture such parallelization may increase overall computation cost.

At the end Daniel talked about physical resources from this table from his paper – no comments from me, just take a look at it:

I really encourage you to read Daniel’s papers – all his papers are very well written and pretty approachable (given the complexity of the topics), he’s definitely one of my top favorite paper authors (and was even before I started working with him!)

Thomas Alexander

Thomas Alexander is a Quantum Solutions Developer at IBM. For the last 5 years he worked on putting quantum systems online.

In contrast with previous talks, Thomas focused more on software-hardware interface. He was referring to some of the concepts from this paper.

Here’s a bunch of very good points he made during the talk:

As the systems scale up, so does the complexity, and building a quantum computer requires connecting many subsystems.
QRE is a tool that allows us to predict application requirements. In turn, application requirements allow us to predict system and subsystem requirements.
There’s a co-design loop in designing a quantum computer – saying “I want to run this application” forces a series of design decisions down the stack. This is a hard optimization problem with tradeoffs everywhere.
There is no “quantum computer” today. There is just a device. What turns it into a QC is plenty of calibration and characterization routines that bootstrap this device into a quantum computer.
In the near term, you need to really optimize all the elements to make things work, so you need to understand many subsystems, which is hard.
Today most QRE focus on circuits (logical or physical), but enabling higher-level abstractions will allow to reduce the information flow throughout the system. For example, when you’re sending info about expectation value instead of all the measurements, there’s much less info to be passed between subsystems.
We need to start introducing reusable subroutines.
Right now we use a small number of inputs for doing QRE, but from the perspective of operating the system, the number of parameters is much higher. However, on the existing devices each qubit is a special snowflake and to get any performance you need to finetune using knowledge about each qubit. We need to get to a world where all the qubits are fungible and we don’t need to worry about their individual characteristics.
Quantum IRs – compilation should scale at most polynomially, but ideally linearly in terms of numbers of gates or qubits. Right now it’s pretty slow, we need to introduce better IRs to make this process more efficient.
Most representations don’t support non-linear control flow, which will be a problem as we start thinking about more advanced protocols.
To get the most out of the device it’s important to understand how your big program is being distributed among multiple smaller devices which control different aspects of the overall QC.
To run those weeks-long algorithms, we will need to keep the devices up for days.
Reliability and efficiency of machines are critical for long-running applications.

Tools

The last part of the workshops was a session where various people gave 5-10 minute presentations on the tools they’re developing and then some time for having discussions with the developers.

We had:

Athena Caesura from Zapata AI presenting Bench-Q
Matt Harrigan from Google presenting Qualtran
Mariia Mykhailova from Microsoft presenting Azure Quantum Resource Estimator
Kevin Obenland from MIT Lincoln Lab presenting pyLiqtr
Michał Stęchły presenting PsiQuantum’s symbolic QRE tools.

While this section is short, I recommend checking out all of these tools and seeing if there’s anything useful there for you. If the topic of QRE is of interest to you, I really think it’s crucial to get acquainted with at least some of them!

Summary

There have been a couple of points that appeared in multiple places throughout the workshops, so I think it’s worth putting them all in one place:

QRE is important, but it’s equally important to be confident that the programs we’re running are correct.
We need better tools for performing QRE – and in the last part of the workshop we have seen that some of those tools are being created right now, hurray!
We also need better abstractions and data formats.
QRE is an important bridge between applications and hardware development.
There are plenty of optimizations at the level of compilation that we still need to work out.
There are many, many assumptions being made while running QREs, which undermines their reliability. But also given where we are, that’s the best we can get and it constantly gets better.

Closing notes

Overall, I am really happy with how the workshops went! It spurred a lot of interesting discussions, I hope we’ll organize another one in 2024. It’s great to see forming of the community around QRE! There was so much good energy around it, that I thought it would be good to help with the “community forming”. That’s why I’ve created a Discord server to facilitate discussions on the topic and perhaps spur some future projects. We even had our first talk. If you’d like to join it, this link will be active for 7 days after publication of the blog post. After that, please send me an e-mail to get an invite :)

And once again, huge kudos to the people who helped organize the workshop:

Peter Johnson
Simon Tsang
Kevin Obenland
Omar Shehab
Mathias Soeken

Have a great day!

Michał

Random acts of kindness

Sat, 21 Oct 2023 10:30:00 +0000

Dear Reader,

My main motivation for doing most things I do in my life is that I want to make the world a better place. And as much cliche as it is, well, it is what it is.

I’ve recently watched a clip from Jordan Peterson’s lecture and something that really resonated with me was the following quote (even though that wasn’t the main point of the talk):

You’re a node in a network. (…) You’ll know a thousand people at least, over the course of your life. (…) And the things you do, they’re like dropping a stone in the pond. The ripples move outwards and they affect things in ways you can’t fully comprehend. And it means that the things that you do and the things that you don’t do are far more important than you think.

We all have an impact on the world around us. It doesn’t always have to be a big impact, but sometimes small things matter and can just create a little bit more happiness out of thin air.

I think the culture we live in has a lot of issues, social alienation and lack of trust being one of them. And it is our actions, which on aggregate, create culture. So why don’t we change that bit by bit?

I personally have experience of living in two countries – Poland and Canada. In Poland, our national pride is in complaining, and so, the negative attitude is the default. Canadians on the other hand, are most well-known for being nice. And the fact that by default, strangers are nice to each other rather than by default being neutral (with a splash of distrust) really makes a difference in the quality of life.

So here’s a list of things which I sometimes do. Things that require minimal effort and are directed towards people I don’t know. Acts of kindness to random strangers. I hope it will inspire you to do them as well.

Compliment people whose work usually goes unnoticed. Or even better – people who, by design, go unnoticed if they’re good at their job. A couple of months ago I was at an event where a string orchestra was playing on a street. Getting the sound right in such settings is not simple, there are plenty of things that can go wrong. But everything sounded great so after they were finished I went to thank the sound technician for doing a good job. Another example – at the conference during a coffee break there were a couple of servers who were bringing food, taking dirty cups, etc. I stopped one of them and thanked one of them for doing his job well.
Smile at people. Whether on a street, on a bus, in a store, whenever you make eye contact, remember to smile.
When something you read on the Internet was really good, send an e-mail to the author saying: “Hey, I really liked your article. It was a good read, it really made me think!”. You don’t need to elaborate on how it changed your life or anything like that. Just letting someone know you read and liked it is a super nice thing already! Don’t take my word on it!
If you ride on a full bus and the stops are frequent, if you’re not in a rush you can get off one stop earlier and just walk those extra 5-10 minutes. This extra breathing space that you’ll create is not much, but it always makes it a tiny bit more comfortable!
Pick up trash from the ground. Our streets (and forests) sometimes look really terrible. It doesn’t take much to pick up stuff and throw it in a garbage bin. Also, when I see someone throwing a cigarette on the ground I pick it up and tell them that it should go to trash. Well, perhaps not the kindest thing to the person, but I find it kind to society.
Be patient. Sometimes there’s a long line in some office and the clerk tries their best but it’s not their fault things go slowly. And people in the line get angry, cause it takes so much time. Relax, notice that they try to do their best and even if you’re in a rush and annoyed, don’t lash out at them. Sometimes the system is broken, sometimes it’s bad luck, not necessarily their fault.
When I used to work at the office, when I was taking a break I sometimes just took a couple of apples, cut them in pieces, and offered them to the people I was passing in the office on my way back to my desk.
If you have stuff you no longer need, give it away. There are plenty of apps that allow you to do that. You gain some extra space and one less thing to worry about and perhaps someone will get what they need. I recently gave away a bunch of Polish books my kids outgrew and someone from Alberta wanted them, so I sent them a parcel. Win-win!
When you are in a supermarket and you see that the person behind you has only two items, while you have a full cart, just let them go first. Or in any other place where someone is nervous and seemingly in a rush – let them pass.
Hold the door for someone when you’re entering/exiting the public space. And if that’s a lot of people, just stand there for a minute until all the people leave.
When the airplane lands, if you don’t have a good reason, don’t rush to the exit. There’s a good chance that some people in that plane have a good reason to rush out. Also, plane boarding is already inefficient enough.

There are a lot of other things you can do to make the world a slightly better place for others and I encourage you to do them! These were only some that:

I’ve personally did
Truly don’t require much effort nor any money
You can do for strangers, not your friends or family

Another good source of inspiration is Random Acts of Kindness website. If this blogpost inspires you to do sth kind to a stranger, please let me know at michal@mustythoughts.com! And if this resonates with you, perhaps the idea of Effective Altruism will also resonate with you :)

And for any Poles reading it, here’s a song by Łona which particularly resonates with me on this topic.

Have a nice day!

Michał

QAOA - challenges and state of research

Tue, 09 May 2023 10:30:00 +0000

Dear Reader,

Today we will delve into the details of QAOA – variational quantum algorithm for solving combinatorial optimization problems.

We already covered a lot in previous articles in this series, so I highly recommend going through that first, especially articles 2, 3 and 4, as they are all very relevant.

VQE — how it works
QAOA — how it works
VQAs - how do they work
VQAs – challenges and progress
VQE — challenges and progress
QAOA — challenges and progress (this is the one you’re reading)

Update: about a month after writing this a review paper on the topic came out by Blekos et al.. I don’t refer to it in the blogpost, but it covers many of the variants of QAOA and is much more comprehensive than this blogpost could ever be! I recommend reading it to anyone interested!

QAOA vs QAOA

Before we even get into a detailed discussion about the algorithm itself, let’s first talk about naming. The original QAOA algorithm presented by Farhi et al. is called Quantum Approximate Optimization Algorithm. However, in 2018 Stuart Hadfield et al. presented a more general algorithm which is called Quantum Alternating Operator Ansatz. Which also spells “QAOA”. You might have a couple of questions now:

Why would they do that?
What’s the difference between these two?
If I hear “QAOA” what exactly do people mean by it?

Let me quote the Hadfield’s paper:

We reworked the original acronym so that “QAOA” continues to apply to both prior work and future work to be done in this more general framework. More generally, the reworked acronym refers to a set of states representable in a certain form, and so can be used without confusion in contexts other than approximate optimization, e.g., exact optimization and sampling.

This means that “the original QAOA” is just a subset of “a more general QAOA”. One of the differences is that in the original QAOA the Hamiltonians which we use are defined in a specific way, while the more general framework allows for much more flexibility. Plus the more general framework is not designed specifically for “approximate optimization” but also for other uses.

So if you hear “QAOA” which one people mean? Well, I’d argue that most of the time people mean the “more general QAOA”, even if they don’t necessarily realize that or what’s the actual difference. I think that most of the time if someone means “original QAOA” specifically they refer to it as “vanilla QAOA”, “basic QAOA”, “Farhi’s QAOA” or something similar.

There are three topics I wanted to talk about, which are more about the problems we’re trying to solve rather than the QAOA algorithm itself. Dealing with these challenges is important for any algorithm which tries to solve optimization problems, quantum or classical. Some are more apparent in one class of algorithms, some in others, but over the years I learned that they all can heavily influence the results of your optimization routine, so I think it’s worth discussing them here.

These are:

Problem formulation
Constraints
Problem encoding

Problem formulation

In general, when you try to solve optimization problems, there is a huge payoff for understanding your problem better and coming up with a better formulation. By formulation I mean understanding the real-world problem and expressing it in a way that an algorithm can solve and maybe adding some problem-specific improvements to the algorithm. This is in opposition to coming up with a better optimization method for a given class of problems, fine tuning it, etc.

Let’s take a look at the following problem – you are in charge of IT infrastructure at a campus. You have a team of 5 people and you have to service equipment in various buildings at the campus. Every day you get calls from people around the campus about the issues that your team needs to solve. For each request you:

identify where the issue happened
estimate how long it will take to solve it.

The problem is how to assign your team in an optimal way?

One approach would be to model this as Capacitated Vehicle Routing Problem (CVRP, it’s a more complicated variant of Traveling Salesman Problem).

In such formulation you can say that:

The capacity of each person is 6 hours per day
Each person shouldn’t spend more than 1 hour driving around the campus, which translates into a constraint that the route itself needs to be under 1 hour.
You are fine with not solving all the requests every day (i.e. not visiting all the cities)

You also decide that your cost function is the number of issues you can solve per day.

Do you think it’s a good formulation?

Well, it depends. Below you can find a couple of questions that one needs to ask in order to model this specific problem better:

Are all the people on the team equally skilled? If one of them is new to the job and another one is a veteran, you should probably start expressing the time estimates differently, e.g. depending on one’s experience or in abstract “points” rather than time. In the latter case, the expert person would have higher capacity.
How accurate are your time estimates for solving those problems? If they’re not very accurate, the mathematical model might have a huge mismatch with reality. If they’re not very accurate, can you model how inaccurate they are, perhaps using a normal distribution?
How much time does it take to travel between different buildings on campus? If there are 3 buildings which are all 5 minutes apart, perhaps it’s worth modeling them as one node – that would decrease the complexity of the graph. If getting from one building to another takes less than 10 minutes, perhaps it’s negligible and you would be better off modeling it as a scheduling problem and not CVRP?
Do issues have different importance?
Given that your cost function depends on the number of problem solved per day, it might lead to a situation where one 6-hour long problem never gets scheduled, because there are always multiple 1-hour problems popping everywhere. Is that acceptable?
Can some problems be solved remotely? If so, how would you model that?
What if a particular problem takes more than a day to solve?

I hope that’s enough to make this point, perhaps the most important from the whole blogpost:

You can have the absolutely best algorithm for solving combinatorial optimization problems, but in the end, if your problem model doesn’t match reality well, who cares?

Constraints

Imagine you have a store and you sell two products: X and Y. You want to maximize the profits from selling them. Profit equals revenue minus cost:

\[P = R - C\]

Revenue is equal to the amount of X sold times its price and same for Y.

\[R = p_x x + p_y y\]

The costs are trickier, as the more products you have, the pricier it is to store it:

$C = c_x x^2 + c_y y^2$.

Your goal is to order the optimal amount of X and Y so that you can maximize your profit.

Well – that’s a simple quadratic function. You can solve it analytically or just use a simple gradient descent optimizer and find it in no time. But let’s add some constraints to make it more realistic. Let’s say you have a limited capacity of your storage, so:

\[0 < x + y < C_1\]

Also, they shouldn’t be negative: $x >= 0$ and $y >= 0$.

On top of that, your supplier tells you that process for creating X and Y is correlated and you can’t just buy only X or only Y, but there’s also some upper cap on their production in relation to each other, so you need to add the following constraint:

\[C_2 <= x * y <= C3\]

Oh, and on top of that, X is sold in discrete quantities ($x$ is an integer), but Y is a liquid so you can buy any quantities ($y$ is a real number).

Well, now our problem is much more interesting and it’s not immediately obvious how to solve it. As you might guess, people came up with some techniques to deal with such constraints. Unfortunately not all of these methods are applicable to all types of cost functions, all types of constraints or all types of optimizers. As it’s quite a broad topic, here I’ll focus only on two methods that you might encounter in QAOA-related literature problems.

First of them works by using something called a “penalty function”. It is a way of modifying your cost function, by introducing some artificial terms which would “penalize” if the variables don’t meet the constraint. Let’s use our favorite MaxCut. As you might recall from previous parts, the cost function of MaxCut is:

$C = \sum_{(i,j) \in E } w_{ij} (1-x_i x_j)$,

where $E$ is a set of all the edges in the graph.

But what if we had a constraint that one group needs to consist of exactly 5 elements? How could we express it mathematically? Since $x_i$ is either 0 or 1, we can arbitrarily say that we want the group represented by ones to have exactly 5 elements. In such a case we know that $\sum x_i = 5$. We can also rewrite it as: $5 - \sum x_ii = 0$. How do we incorporate this in our cost function? Well, here’s the trick. We transform it into the following term:

\[P = P_1 (5 - \sum x_i)^2\]

and then just add it to the cost function:

\[C_{new} = C + P\]

Since we want to minimize the value of $C_{new}$, any solution $x$ which doesn’t meet the constraint will make the value of $C_{new}$ higher, so it will be a worse solution. Since $P_1$ is an arbitrary constant which doesn’t have any real-world meaning, we can select it to be arbitrarily high. E.g. if our values C are usually in the range of 0-10, we can set $P_1=100$, so that any minor violation of the constraint would result in an extremely high penalty to the cost¹. Basically what we did is we transformed a constrained problem (cost function C and our constraint) into an unconstrained one (just cost_function $C_{new}$ without any constraints).

This method has some pros and cons – it’s relatively simple and it works for basically any problem, as you can always modify your cost function. However, it doesn’t work well with all types of optimization methods and is a little bit more tricky to use with inequality constraints (i.e. $\ge, \le$). You can find examples of this being incorporated into the cost function in everyone’s favorite “Ising formulations of many NP problems” by Andrew Lucas, see e.g.: section 7.1 . Another example of how to do that is in section 3.1 of this paper (again by Stuart Hadfield)².

There is another way to avoid getting solutions you don’t want, and it works particularly well with problems where solutions have some inherent structure, as is the case for many combinatorial optimization problems. Let’s take the Traveling Salesman Problem (TSP) as an example³. For 5 cities the solution can look like this: [5, 2, 3, 1, 4], which specifies in what order we visit cities. An incorrect solution might look like this: [5, 2, 3, 1, 2] – as you can see we’re visiting city 2 twice in this case, but we’re missing city 4, which violates the constraints.

How can we ensure our solution is always correct? There are two components to the solution:

Start from a valid solution (i.e. one doesn’t violate constraints)
Create new solutions by performing only operations which transform a valid solution into another valid solution.

In the case of TSP such operations would be swapping elements in the list. So we could transform [5, 2, 3, 1, 4] into [4, 2, 3, 1, 5], which is also a valid solution, but with this method we would never get anything like [5, 2, 3, 1, 2].

Easy to do with lists, but how does one do that with quantum states? I talk more about it in the section about alternative QAOA ansatz!

Encoding

Another important topic is how do you encode your problem to fit a particular algorithm. Let’s think about how to describe the TSP problem in a mathematical form and different ways to encode solutions to it.

The most natural (at least for me) way is to define a distance matrix. It is a matrics which tells us what’s a difference between each pair of cities. For three cities it can look like this:

	A	B	C
A	0	5	7
B	5	0	10
C	7	10	0

We know that the distance from A to B is 5km, from B to C is 10km and from A to C is 7km. How would we encode the solution? Simply as: [A, B, C], [B, C, A] etc.

We can easily switch to integer labels (A=>1, B=>2, C=>3), which will make some math down the road easier (like indexing rows and columns of the distance matrix).

Ok, but what if our machine has a limited number of integers it can work with for expressing the solution. In the case of a quantum computer it’s actually just 0 or 1. So how would we encode the solution to our 3-city problem?

Well, there are multiple ways to do this. The simpler one (perhaps) is called “one-hot encoding” or “unary encoding”. In this encoding, we encode each city like this:

A -> 100
B -> 010
C -> 001

Now if we want to represent a route: A -> C -> B, we can write it as “100 001 010”. Each bistring will consist of three blocks, each represent one moment in time. And then each block will consist of three bits, each representing a city. So in this case having “001” in the middle means, that we visit city “C” in the second time step. This allows us to easily encode constraints, such as “you can be only in one city at the time”, as you just need to check if any given block contains only a single 1.

However, one thing people often say when looking at the unary encoding is that it’s very space inefficient. Indeed, it will take you $n^2$ bits to encode a solution for the problem with $n$ cities. So perhaps we could use binary encoding. In this case we will have:

A -> 00
B -> 01
C -> 10

Now, we use only 6 bits to encode the solution and it actually scales as $n \cdot log(n)$, which is pretty good!

There are, however, a couple of issues here. First, the bitstring “11” is undefined. You can write a route containing it, but it doesn’t mean anything. One way to deal with it is to add a constraint that will prohibit its occurrences, but it adds more complexity. Second, encoding the “basic constraints” of the problem, like “each city needs to be visited only once” is more involved than in the previous case.

There’s plenty of trade-offs when it comes to choosing encoding, and you can come up with many different variants (or even combining multiple encoding at the same time). I won’t get into any details, but if you are interested, I recommend reading this paper by Nicholas Sawaya et al.

We didn’t even discuss how those encodings impact the construction of the cost Hamiltonian for our problem, as it would be rather tedious. I just wanted to signal this as another important decision which you need to think about when you try to solve optimization problems, especially with quantum computers.

Parameter concentration

Ok, now we’re done with those “general optimization topics”, let’s get into some QAOA-specific topics. Let’s start with a very interesting phenomenon first described by Brandao et al. Consider a class of problems: MaxCut on 3-regular graphs⁴. Let’s take one problem instance (i.e. one specific graph) and find good parameters for it. And now let’s take 100 other graphs of the same size and see how well these parameters would do?

It turns out that good parameters for one instance work very well on 100 other similar instances of the same size. But that’s not everything – they also work very well on graphs of different sizes, but of the same type. So for example a graph with 10 nodes and the other one with 20 nodes. Also, good parameters work equally well and bad parameters work equally badly. This inspired us to do a little bit of investigation with the visualization package we developed at Zapata, orqviz. As you can see in the plots below, for several graphs from the same family which differ in size, the cost landscapes look very similar around the same parameters. I’m skimming over a lot of details here, see the paper for details.

It’s pretty crazy if you think about it – we can take one graph, find good parameters for QAOA and just use them for another graph and it just works. For now this has been investigated only for simple types of problems and I don’t think this will hold for much bigger real-world problems, but it’s still an extremely interesting phenomenon to investigate. I think this paper by Jonathan Wurtz gives some insight on what might be going on, especially for 3-regular graphs.

Modified cost functions

In many VQAs we are interested in calculating the expectation value of a particular operator. This is a very reasonable thing to do if the expectation value is what we’re looking after. While using QAOA the expectation value corresponds to the value of the cost function. However, we don’t really care about the value of the cost function. Sure, it would be nice to get to the minimum, but its numerical value is usually not what we’re after. What we are after is the solution of our problem which gives us this low cost function value.

Before we go further let’s revisit a basic question: how do we use quantum computers to calculate the expectation value?

We run a particular circuit and obtain a bitstring.
We use this bitstring to calculate the energy value based on some Hamiltonian.
And since quantum computers are probabilistic, we need to run it N times to get good statistics.

Now let’s imagine that we have an ansatz and two sets of parameters. Here are two tables, one shows the energy of each bistring and the other one the measurements we get when we run the circuits with those two sets of params:

	Energy
bitstring_1	10
bitstring_2	1
bitstring_3	0
bitstring_4	1000

	bitstring_1	bitstring_2	bitstring_3	bitstring_4	expectation value
params_1	900	100	0	0	9.1
params_2	0	0	900	100	900

Which set of params is better?

Well, if we just look at the expectation value, the first one is much better. But if we also look at the quality of the bitstrings we obtained – that’s a different story. Second set of parameters gives us bitstring_3. And bitstring_3 has the lowest energy value from all the bitstrings we’ve seen for this problem – perhaps it’s even the best possible solution to our problem? And, as we mentioned, in the optimization problems we are more interested in obtaining the best possible solution to our problem, rather than obtaining the best expectation value.

The phenomenon we see here is a result of superposition. In the case of Ising Hamiltonians representing combinatorial optimization problems, there is a quantum state which gives you a particular bitstring (representing your solution) with 100% probability. But since we have superposition, we can have states which represent more than one solution at once (as seen above). This results in this somewhat unintuitive situation, where we have a state with higher expectation value which provides a much better solution than another state with lower expectation value. Can we do something about it? Sure we can!

What if we simply discarded 50% percent of measurements with the highest cost value? This is how our table would look like:

	bitstring_1	bitstring_2	bitstring_3	bitstring_4	expectation value
params_1	400	100	0	0	8.2
params_2	0	0	500	0	0

This technique is called CVaR and has been proposed by Barkoutsos et al.. It can also be applied to other VQAs, I recommend checking out the paper as it’s a really good read. Results in this follow-up work suggests that CVaR is a must-have tool in anyone’s QAOA’s toolbox. It’s worth mentioning that apart from CVaR, there is another method which works similarly, called “Gibbs Objective Function”. In this case the cost function is defined as:

\[f = - log(e^{-\eta E})\]

By using such a cost function instead of a standard one, we increase the weight of the low-energy samples. The original paper by Li et al. provides a good intuition about how and why it works, so if you’re interested, I recommend reading section III of it.

Other ansatzes

One of the fundamental building blocks of VQAs is ansatz. We discussed its importance in detail in the post about VQAs and what are some considerations in using one versus another.

In the first QAOA post we have described the most basic version of the ansatz for QAOA, let’s do a quick recap here.

QAOA ansatz is generated by two Hamiltonians, summarized by the following table:

H_B	H_C
Associated with the angle beta	Associated with the angle gamma
Independent of the cost function	Is defined by the cost function
Called “Mixing Hamiltonian”	Called “Cost Hamiltonian”

QAOA creates the state: $| \gamma, \beta \rangle = U(H_B, \beta_p) U(H_C, \gamma_p) … U(H_B, \beta_1) U(H_C, \gamma_1) | s \rangle$, where $U(H_B, \beta) = e^{-i \beta H_B}$ and $U(H_C, \gamma) = e^{-i \gamma H_C}$ and $|s \rangle$ is the starting state.

There can be a lot of variation in how you construct the circuit within this framework, here I will go through two of them: Warm-start QAOA ansatz and Hadfield’s QAOA.

These are by no means the best possible ansatzes, but I think they show well how one can approach constructing new ansatzes.

Warm-start QAOA

In optimization we have a concept of “warm-starting” the optimization process. It happens when we use information from previous optimization runs to start with some reasonable initial parameters. In QAOA we can use some classical optimization process to get some reasonable solutions. Then we can inject this information into our ansatz, which hopefully will work better now. How does it work in practice?

Let’s say we have a problem, for which the solution is a binary string, and a classical solver which can solve a “relaxed version” of this problem. “Relaxation” here means that instead of limiting ourselves to integers, our solution can contain any real number between 0 and 1. This is reasonable, as often continuous versions of a problem are simpler to solve than discrete ones. We denote our classical solution as $|c|^*$ and based on this we construct a vector $\theta$ for which every i-th element is defined as: $\theta_i = 2 \arcsin{(\sqrt{c_i^*})}$. Now for the initial state we use state, where each qubit is set to $|i \rangle = RY(\theta_i) |0 \rangle$. In this state the probability to measure given qubit in state $|1 \rangle$ is equal to $c_i^*$. On top of that, we also modify the mixing Hamiltonian to the following form:

\[H_M^{ws} = \sum_{i=0}^{n-1} H_{M,i}^{ws}\]

where

\[H_{M,i}^{ws} = -\sin{\theta_i} X - \cos{\theta_i} Z\]

and $X, Z$ are Pauli operators. This is easily implementable using $R_Y$ and $R_Z$ gates.

There is a lot more to this, so if you’re interested I recommend Egger et al which shows how this basic idea can be extended and elaborate much more on why these choices have been made. Also, it’s worth noting that there are other approaches to warm-starting QAOA, such as Tate et al (and the follow-up work).

Quantum Alternating Operator Ansatz

This section is about the framework that was proposed by Stuard Hadfield (his thesis and Hadfield et al.). I won’t go into too many technical details about it, as it’s described very well in there, with examples for specific problems and reasoning behind it. Here I would like to just give you a general understanding of how this family of ansatzes work. As initially proposed, it was intended to be used with constrained problems (please read the section about constraints first if you haven’t already).

The main idea is as follows:

Start from a quantum state which represents a valid solution.
Use mixing Hamiltonian which allows you to evolve your state only within feasible subspace. Which means it transforms quantum states representing valid solutions into other quantum states representing other valid solutions.

Therefore a circuit here is built from three elements:

Initial state – we need to start in a state which represents a feasible solution to the problem. Not the optimal one (this would pretty much kill the purpose), but just some which doesn’t violate any constraints. This can also be a superposition of multiple feasible states, which usually gives better results.
Mixing Hamiltonian – this Hamiltonian is responsible for changing the provided state. So it can be implemented in such a way, that we only allow for the operations that transform feasible states into feasible states. For example in the case of TSP this means having a Hamiltonian which represents list permutation. It also gives a more flexible framework for constructing these operators, as they no longer need to necessarily be exponentials of a single Hamiltonian, as in regular QAOA.
Cost Hamiltonian – this is our old good cost Hamiltonian, no changes here :)

As I’ve learned in some of my own projects, implementing an ansatz from this class can give you a significant boost in the quality of the results. However, it comes at a price – those circuits are usually deeper than the alternatives. Let’s discuss such tradeoffs in the next section!

Implementation tradeoffs

As we discussed, solving a problem using QAOA requires making several decisions – how to formulate the problem, how to encode it into an Ising Hamiltonian, what ansatz to choose, which cost function to use, etc.

Each of these comes at a certain cost – let’s look at the choice of the ansatz. When we consider different options it seems that Hadfield’s ansatz looks like a decent idea. However, it incurs some extra costs – first, we need to create the initial state. Depending on the particular case, it might be either easy and cheap (in terms of number of required gates) or very non-trivial, especially if we want to create a superposition of many feasible initial states. Another hurdle is implementing the mixing Hamiltonian. The standard “all-X” mixing Hamiltonian can be implemented by a single layer of RZ gates. On the other hand, some of the Hamiltonians proposed in the paper are pretty complicated and implementing them might require creating a circuit with hundreds of gates. Fortunately, the cost Hamiltonian will be the same most of the time.

Let’s say that for the particular problem that we want to solve, the circuit using Hadfield’s ansatz is 10x longer than the basic one. This means that it will run 10x longer. Can this be even worth it? Well, it might turn out that our ansatz gives us the correct answer with 10% probability, while using vanilla ansatz it would be 0.1%. So even though we need 10x more time to run our circuit, we need to run it only 100 times, to get 10 good samples, while with the basic version, we would need to run it 10000 times. Therefore, using a more expensive ansatz would still give us an order of magnitude improvement in the runtime.

Obviously, this is an overly simplified toy example – in the real case the analysis would be much, much more difficult to do – we would need to model how different circuits are susceptible to noise, try to estimate how fast the optimization of the parameters converges in various cases etc. Taking all of those factors and various combinations into account is impossible and requires extensive experimentation to come up with the set of methods that will be appropriate for solving the problem at hand.

However, certain calculations can be done relatively quickly – for example, if we have some theory to back up a claim that a particular method would require getting 1000 more samples than another one, or if one circuit is 1000x longer than the other one, we can probably rule them out, cause it’s unlikely, they will yield enough benefits, given that they already have 3 orders of magnitude longer runtime. Therefore, it’s always good to look critically at the methods we plan to use – even if it’s not possible to get the precise numbers, we might still get some good insight about the tradeoffs.

Parameter initialization

Imagine two people are looking for treasure on an island. One is a 9 years old girl with a broken leg, walking with crutches. The other one is a 30-years old commando who spends two months a year on survival trips to the Amazon jungle. They both have the same map to the treasure and both start the treasure hunt from different places on the map.

Who is more likely to win?

Well, I wouldn’t bet too much on a girl.

However, what if I told you that the girl was lucky enough to start 10 meters away from the treasure chest, while the guy starts on the opposite side of the island, behind 2 rivers and an active volcano?

This changes the picture.

It’s similar to optimization – you will spend much less time looking for optimal parameters if the initial parameters are close to optimal. And starting from a bad place will make things so much harder for you. Since VQAs are all about finding optimal parameters for a given problem, it’s no surprise that people spend a lot of time trying to find a way for good parameter initialization.

Here I will cover a couple of methods for parameter initialization – layer-by-layer optimization (LBL), INTERP and schedules. One thing before we start – even though I call them “parameter initializations” strategies, they are sometimes tightly related to the optimization process.

The simplest one is LBL – here we start from a small number of layers which is easy to optimize due to the small number of parameters. Once we have found optimal params, we keep them, add a new layer, initialize it with random parms and repeat the process. And again, and again until we reach our target number of layers. There are different variants of this approach, but you can see that it’s pretty resource-intensive, as we have to basically run about N optimization loops, where N is the target number of layers.

This has been improved by introducing a method called INTERP. It’s based on the observation that gammas and betas seem to increase monotonically (see fig. 2 from Zhou et al.). Therefore, we don’t have to initialize the new layer randomly – if we have good parameters for layer N-1, we can predict what would be good parameters for N, tune all the params a little bit and repeat the process. This can be done using a straightforward interpolation, but the authors also suggested a more sophisticated method called “FOURIER” – I recommend reading the original paper, it’s extremely interesting. There is also a recent work by Sack et al, which provides some more theoretical background and intuition why and how INTERP works.

Methods like this will work well for a relatively small number of layers, but what if we talk about the future where we could have thousands of layers? It turns out that in this limit we might be able to get decent results by using something called “schedules”. In this paper the authors decided that they’ll choose values for betas and gammas defined by: $\gamma(f) = \Delta f$ and $\beta(f) = (1- \Delta) f$. Here $f$ has values from 0 to 1 and for a case with a total of $p$ layers, we substitute $f$ with $f_j = \frac{j}{p+1}$ for a $j$-th layer. $\Delta$ is a free parameter we need to pick ourselves. Therefore schedule is basically a curve from which we take our parameters. This work by Sack and Serbyn also discusses similar ideas.

I like how these methods fit together – we’ve seen in the INTERP paper that the parameters change monotonically, so why not just make a simple assumption that the change is linear and see where it leads us? Since finding optimal parameters is an extremely computationally expensive problem, it would be great if using schedules like this (or more involved) would spare us optimizing parameters or provide us with really good initial params. But to see how this will play out in practice, I think we need to start running more of these on real devices.

Closing notes

There are a lot of other developments in the QAOA space. RQAOA, Multi-angle QAOA and ADAPT-QAOA to name a few. However, if I tried to cover all these topics, this would soon become a review paper and not a blogpost, so I had to stop somewhere :)

I hope you found this blogpost helpful in understanding some more advanced concepts around QAOA and now it will be easier for you to explore these concepts by yourself.

And of course, I wanted to thank to people that helped me with writing this blogpost, namely:

Matt Kowalsky
Stuart Hadfield

Since this is the last blogpost in my series about variational quantum algorithms, I just wanted to say that I’m really grateful for all the positive feedback I got from various people who read these articles over the years. When I started writing it 3.5 years ago, I didn’t know it would take me so long to finish it. But here we are! Thank you for joining me on this VQA journey, I learned a lot in the process and I hope you did as well. You can find a PDF-version of the whole series on arXiv.

And if you want to know about other projects I’ll be working on, please subscribe for the newsletter :) I have one cool paper on QAOA coming out very soon and some good content about quantum software.

Have a nice day!

Michał

Footnotes:

In practice, tuning the values of the penalties constants might be a significant problem in itself. Too small and it doesn’t serve its function. Too high and it might lead the optimizer to behave in unexpected ways. Not to mention interplay between multiple penalties! ↩
It also shows how to map real functions to Ising Hamiltonians – something I didn’t know is possible and find it pretty cool! ↩
If you are not familiar with it, you can find an explanation on wiki. ↩
3-regular means that each node connects to exactly three other nodes. So each node has exactly 3 neighbours. ↩

Perfect Quantum Resource Estimation Software

Sun, 30 Apr 2023 17:30:00 +0000

Hello!

For over a year now I’ve been working on software to do resource estimation (RE) for fault tolerant quantum computation (FTQC). I’ve been working on this as a part of the Quantum Benchmarking program funded by DARPA

Being part of this program was an amazing experience, I had an opportunity to work with many great people from all around the world. But this is a story for another time.

In this post I wanted to summarize my thoughts on what would make an ideal software for resource estimation.

Notes before we start: I’ll use “QRE” as shorthand for “Quantum Resource Estimation”. And by “quantum” here I really mean FTQC – nothing I’ll write about has anything to do with NISQ. It might apply, but it’s never my intent. This post is not an introduction to QRE. It’s targeted at people who are working on QRE or related topic and are already familiar with some parts of the stack we’ll be using here. But even so – if you’ll get lost at any point, please let me know in the comments! There are a few tools for resource estimation out there already – Azure QRE or resource estimation module in OpenFermion. They have some of the characteristics of “my dream QRE tool”, but not the others.I won’t mention them anywhere in the text, as I haven’t worked with them enough to be able to do them justice. However, if you’re interested in the topic and haven’t seen them yet, absolutely please check them out :)

Ok, so let’s start!

What is QRE and why is it hard?

Let’s start by briefly explaining what do we mean by QRE? Let’s say you want to know how long it will take to run an algorithm which solves a certain problem on a quantum computer.

I’ll start by making a horrible oversimplification, which sweeps under a rug A TON of problems – you already have a quantum circuit that you want to run on your quantum computer. What to do about it?

Well, since we need to account for error correction overhead, this is not as simple as calculating the depth of the circuit and then multiplying it by gate time. You need to understand how this circuit would be implemented on a real quantum computer, which might require the following reasoning (in the Q&A format):

Q: What gates do I have in my circuit?

A: I have Clifford gates and Pauli rotations

Q: Are these gates something that my error correction method can directly use?

A: Method I’m using can handle only Clifford+T gates, so we need to do something about rotations.

Q: What can I do about rotations?

A: You can either translate each rotation into a sequence of Clifford + T (i.e. gate synthesis), or estimate how many T gates each rotation gate will translate to.

Q: Let’s say we can compile it to Clifford+T. What resources do we even want to estimate?

A: Let’s estimate how much time the calculation will take and how many physical qubits it will take.

Q: Don’t these numbers depend on the characteristics of the physical hardware? For example gate time and gate fidelity?

A: That’s true – we can model the hardware by parameterizing these quantities.

Q: Do we want to distinguish between one-qubit gates and two-qubit gates?

A: For now we can treat them the same.

Q: Ok, how much does it take to implement each gate in a fault tolerant way?

A: It depends on the type of the gate and the failure rate of the whole circuit we want to achieve. You can never have a 0% failure rate, even on classical computers. So you need to specify what failure rate you’re willing to tolerate. In the surface code, for example, you can achieve a lower failure rate by increasing the code distance.

Q: Let’s assume we know the target failure rate. What resources are needed for each gate?

A: Each T gate might require thousands of Clifford gates itself, so as a first approximation we can cost out just them…

Let’s finish it here, as I really don’t want to spend this time getting into the details of how to build a T-gate factory. And how to implement this with the surface code. And how to calculate resources for it. And how those resources depend on the parameters of the hardware (quality of qubits, connectivity, architecture…). And how to take the decoding process into account. And that you can get other resources, such as energy needed or the physical area of the machine you need. Oh, not to mention dealing with space-time tradeoffs…

The main points I’ve tried to make are:

When trying to perform resource estimation, there are a huge number of considerations and assumptions that go into making a particular estimate.
Some of the assumptions depend on the compilation you’re using, some on the fault-tolerant protocols you’re considering, some on the hardware and some others depend on how accurate you want to be.
It’s pretty complex.

Final note – I’m not super happy about the section that you’ve just read. But I really don’t have time to write a 3-part blogpost explaining all the nuances in detail right now, so I’ll just leave it as it is.

Ok, let’s now talk about how these translate into challenges for building a software that performs all of this automatically.

Main challenges

My focus is on challenges on the software level – not what makes QRE hard in general, but what makes it hard to write software for QRE.

Many assumptions

Performing resource estimates comes with many assumptions about the future hardware. The problem is that some of the assumptions might turn out to be incorrect in the future, so you don’t want to hardcode too many of them. Sometimes it’s hard to say what is an assumption and what is not, as some assumptions are not really being stated explicitly (e.g.: “we use surface codes” or “Clifford gates are cheap”). It’s unreasonable to write software without making any kind of assumptions, but managing them is a big challenge in QRE.

Science is changing

QRE as a subfield of quantum computing is a relatively young and small niche, which touches on many adjacent subfields (such as quantum algorithms, compilation, error correction, quantum hardware), all of which are developing rapidly. This means that every year there are many new improvements, algorithms and breakthroughs being made and it’s hard to keep up or have expertise in all of them. It’s very, very hard to find people who have a good, holistic understanding of all the concepts involved – I guess it’s under 100 people in the world, and that might be generous already. Therefore there are not many learning materials on the topic and good knowledge is very scarce. Fortunately it’s easier to find people who have deep understanding on particular parts of the QRE pipeline, but still – this knowledge is very specialized.

Another issue is that there’s no well-established language. It’s common that across many groups people use different words for the same thing or one word has different meaning for each group. This is typical for QC in general and I’ve been complaining about it for years, but it is definitely more acute when it comes to QRE because doing it properly requires input from each group.

A couple of mundane examples of why it makes writing software harder:

we had too many meetings where it took us up to an hour to just understand that we’re talking about two things that were similar, but distinct in important ways. Both sides used the same word for it.
imagine how the code looks like after you rename each variable 3 times…
I think I’ve never worked on a project that had such a steep learning curve – onboarding new people to the project was taking a lot of time.

Ill-defined abstractions

This one is a derivative of the previous point, but it’s particularly problematic when it comes to writing software, so I think it’s worth discussing it separately. In order to do resource estimation you’ll have to go through multiple layers of abstractions (e.g.: quantum algorithms, quantum subroutines, arbitrary logical circuit, transpiled logical circuit (e.g.: Clifford+T), error correction codes, logical qubits, physical qubits). Many of these abstraction layers are neither well defined nor is there common software describing them. It’s also not entirely clear what’s the coupling between all of them, as they seem to be distinct on the paper, until you start writing code. And then it turns out that you actually need to exchange information between them, the boundary is fuzzy and as a cherry on the top, there are some feedback loops.

I’ve been working on designing software abstractions for quantum computing for a couple of years now, and every single time getting it right takes months (if not years) from the first prototypes to actually making things run smoothly. Creating software is an iterative process after all, and since some of the ideas really live only in scientific papers or people’s heads, putting them into code properly is really challenging.

Target group

Given how important the topic is and how many parts of the quantum computing stack it spans, it’s no surprise that there are many potential users of such software. Let’s take a look at who they are and why they are interested in it.

Decision makers

This group contains people who need to make strategic decisions about investing their time and money in quantum computing, when they can expect it to be useful and for what type of problems. They might need to decide, for example, “which quantum computing hardware do I invest in?”

They want reliable numbers, but are not necessarily able to check their correctness – they need to trust the software.
They care mostly about solving a particular problem – an “application instance”.
They don’t care what algorithm or particular error correction method has been used.

Application scientists / algorithm researchers

These are people who are researchers, but do not specialize in error correction, compilation or any of these. They want to solve a particular problem or design a new algorithm and they want to make sure that it uses a reasonable amount of resources.

They want something that’s fast, as they use this tool to get feedback and iterate.
Tool will be integrated into their current workflow, so it needs to be easy to integrate with.
They might use the tool as a profiler, so it would need to have good visualization capabilities. While not being an expert, they might be knowledgeable about various tradeoffs present in the system, so they want to be able to play with various parameters much more than the previous group.

As an example, of this type of usage Microsoft recently posted a blog post where Goldman Sachs researchers used their resource estimation tool in this way.

This is a group whose main interests intersect with how the resource estimation pipeline works ¹. They want to see how it works, they want to tinker with it and they want to test their own ideas and see if they improve the performance of the system.

They don’t want to use the tool to get the final results. They want to use it as a way to improve their own research.
They are potential contributors to the tool.
They will try to break the system and prove that it actually doesn’t work as well as you claim it works. In the end they’re scientists at heart, right? ;)

Hardware providers

Hardware providers are also interested in this kind of tools, as it allows them to model how changes in their architecture impact the capacity to solve utility scale problems.

They need to be able to use sophisticated models of the hardware in conjunction with the resource estimation tools.
Given how many different hardware modalities are there, they might need a lot of flexibility when it comes to manipulating assumptions. For example, the assumption “a quantum computer is just a huge grid of qubits connected to their nearest neighbors” might not allow certain hardware developers to make progress.
They might be interested in estimating resources much different than the other users – amount of materials needed to build, amount of power needed for specific components, etc.

Ideal resource estimation software

Given all these, let’s get back to the question – what should be the characteristics of the ideal resource estimation software? To put it differently – if I had a team of 100 people and 5 years to build it, how would I build it?

Modularity

I think such software should be modular as hell! In order to deal with multiple, constantly changing assumptions, you need to have a very modular system. It would be lovely if the modules were all independent software packages which can serve their purpose without relying on other modules, but I think that’s too much to ask, as I don’t think it’s possible to escape some coupling.

Modularity itself is not enough though, it also needs to have well established interfaces, so one can plug-in those modules. This way you can tame the proliferation of the assumptions, as you can always check which assumptions have been used by just inspecting what was the input data and which modules were used for computation.

Future compilation chain

I think that a resource estimation system of today should be the compilation toolchain of tomorrow.

In order to run something on a quantum computer, we will have to compile the “high level algorithm” into some “quantum machine code”. There’s no doubt about that. Machine code would be a source of truth about executing a given program – the only thing that will allow us to have a more precise view of how much resources would the execution take is the execution itself.

So “in the limit”, if we had a resource estimator that work on the machine code level, we could compile everything to the machine code and then we would have perfect resource estimates – beautiful! Even better – such an approach would allow us to take advantage of various hardware-level optimizations, which are not possible when we’re operating on a more abstract level. However, this introduces a whole host of technical difficulties and is definitely not very practical in the short term. It would be overly complex and resource intensive, not to mention that we don’t really even have a good idea of how such machine code would look like².

Still, I think striving for this is a useful approach, as it forces you to make the resource estimates more realistic.

This approach stands in opposition to what we internally call “footprint analysis” – i.e. an approach where you only count the number of T gates, see how much “footprint” each T gate has (in terms of space and time) and then calculate the resources based on that. I think both approaches have pros and cons, but I believe in the long run the more detailed one will turn out to be more useful.

Well defined abstraction layers

I think that it’s impossible to build a system which is modular and flexible without defining what are the abstraction layers, what are the basic data structures and interfaces and how they interact. Today abstractions all float around the concept of “quantum circuit”, and this is not a good abstraction for multiple reasons (see: my previous post).

We need both better higher level abstractions (quantum programming languages really) and lower level abstractions.

Multiple entrypoints

As mentioned before, different users have different needs and different goals. Therefore, we would need to allow different users to use it differently.

Non-quantum domain experts don’t want to deal with details of specifying quantum algorithms. They want to know how long it will take for a quantum computer to perform simulation of the dynamics of a particular molecule. So they should be able to specify what molecule they care about, what properties and what they want to do with it (e.g.: find ground state, excited state, or just evolve it over time).

Quantum algorithm researchers might want to work at the level of an algorithm, see how costly different pieces of the algorithm are in practice and how to optimize them to get better results.

Compilation researchers might totally not care about the problem they are solving – they just want to know if their particular new compilation technique works well across a wide range of algorithms.

It might be similar for hardware providers – they would care most whether their hardware is modeled accurately in the software and less about the choice of the active spaces that’s used in order to prepare the molecule’s Hamiltonian.

I think it’s also important that such software would have a library of “ready-to-go” components that new users can immediately start experimenting with. Some high-level instances, some algorithms, some hardware models etc.

High quality results.

The numbers that we get at the end of the resource estimation process need to have a couple of qualities.

First, they need to be correct – i.e. we want to make sure that the formulas we’re using to obtain them are correct and that there were no mistakes in how they have been calculated.

Second, we want them to be realistic – it’s great that we have a number which has been calculated correctly. However, if it came from using unrealistic assumptions, it doesn’t really provide much value. And believe me, making sure your assumptions are realistic is by no means simple.

Third, we want them to be optimized – it’s nice that we got some numbers using realistic assumptions. However, realistic assumptions don’t ensure that we have optimized different parts of our system. Perhaps we used an old algorithm for gate synthesis and we have an unnecessarily high T-gate count? Or we didn’t make use of the fact that qubits have all-to-all connectivity and we just assumed nearest neighbors? Well, it’s not “incorrect” to do that, but it leaves a lot of room on the table for getting even lower numbers once you optimize things like this.

Fourth – I want my dream QRE software to produce numbers which have error bars. Error bars are important!

Scalability

At some point the scale of the calculation cannot be done on your laptop, the problem size just gets too big. In such a case, I’d love to be able to seamlessly switch to some distributed computing system that handles all the scaling for me.

I might be biased, but it sounds like a perfect usecase for the Orquestra platform that’s being built at Zapata…

Visualization

I think that the software should have some good way of visualizing the outputs. Different things might be important for different types of users, e.g.:

Showing how many resources each part of the algorithm uses.
Plotting multiple problem instances on one chart to see how various resources scale with changing size of the problem or target accuracy.
I could even imagine visualization for a given hardware model which would show which parts of the hardware has been underutilized, which might hint at where it can be further optimized.

I’m a big believer in good visualization making making huge difference, so I really think this shouldn’t be overlooked!

Hosting

I think that the system like this should be available in at least a couple of flavors – again, this will allow to meet needs of different users.

Standalone library – I think plenty of researchers and developers will prefer to like to play with such tool locally at first. It’s just so much more convenient to test things on your own machine.

Rest API – on the other hand, there are plenty of scenarios, where you might want to have access to an easy to use API. It allows to offload some of the calculations to external server and makes it easy to integrate with certain services.

Web App – I think for the most high-level users a web app with an intuitive interface is something that would fit their needs best. No installation, easy access, no need to see what’s inside.

Open-source

Damn, I just believe in open-source, so if this is my list I’ll just throw it in ;)

But more seriously – obviously various organizations will have different concerns about open-source so it’s not that simple. But apart from all the benefits and challenges associated with OSS, here are some points that are particularly important in this area:

Reliability – the problem is quite complex. Therefore, the transparency and the ability to inspect the code and let the users find potential issues is really important in this case. Especially if your users are world-class experts. Easier to collaborate – if there are 20 people in the world who understand a particular algorithm you’re using (most probably based on one of their old papers in one way or another), then it will be great if you discuss it with them. Much easier with OSS.

Obviously, not all parts of the system make sense to be open-source for every player. For example, the hardware providers might very much not like to make detailed models of their hardware public. However, I still think that an “open-core” model would be the best approach. I believe things such as:

interfaces
datastructures
basic flow
API

should be open, as they will make it easier for various people to cooperate and integrate with the system, while specific implementations of some of the interfaces can well be closed-source proprietary black boxes.

Well documented

This one’s pretty obvious. Things just need to be well documented and given the complexity it needs to have multiple layers of documentation:

Very basic “intro to the topic” tutorials
Code examples for the most common use cases
Deep scientific dives explaining in details the methods being used
API docs
Probably many others I didn’t think about at the moment ;)

Well tested

It goes without saying, but a system like this needs to be well tested. And with different modes of testing – unit tests, end-to-end tests, integration tests, performance tests.

BenchQ

I think it’s not surprising that the reason why I have so many thoughts on the topic is because for more than a year I’ve been developing such software. It’s called BenchQ and we’ve been developing it at Zapata in collaboration with people from University of Technology Sydney, Aalto University, University of Texas at Dallas, Keio University, IonQ and Rigetti Computing. This has been done as a part of the DARPA’s Quantum Benchmarking program.

We tried to get a lot of the points that I listed above right. However, since in real life there are plenty of constraints, it doesn’t fit perfectly into the picture I’ve just painted. If anyone is interested in learning more, please let me know in the comments – I could write a “case-study” blogpost where I show how various design choices we made fit into the framework above.

If you’re interested, please feel free to try it out, as it’s open-source: benchq. It’s still very much in development, not very well documented, so please don’t be too harsh – rather create a GitHub issue or contact the developers³.

Closing notes

I hope that someone managed to get through this wall of text :)

Huge thanks to Peter Johnson, who reviewed this post on an extremely short notice. And who is the most brilliant, most awesome and most handsome PI that this program ever had or ever will have ;) And also to everyone we worked with on in this project, definitely one of the most intense learning experiences in my career so far! Unfortunately that’s too many people to list here.

Have a wonderful day!

Michał

Footnotes:

This includes specialties such as error correction, compilation, decoding, etc. ↩
Perhaps some people do! Though I really think we’re not there yet. ↩
Since I’m no longer involved in this project, no point in contacting me, cause I’ll redirect you to other people anyway :) ↩

Let's move beyond circuits

Mon, 26 Sep 2022 12:30:00 +0000

Let’s move beyond circuits!

Last week I attended IEEE Quantum Week conference in Colorado. Out of all the wonderful conversations, presentations and discussions, there is one thought that felt particularly important, which I encapsulated in this tweet:

Before Quantum Week:
"I have this idea, that perhaps circuits are not a good abstraction for QC. Maybe I'm wrong I hope it's not too controversial."
After Quantum Week:
"Hell yeah, circuits are terrible! Everyone thinks so, let's figure out something better!"
— Michał Stęchły (@mstechly) September 22, 2022

There was some discussion in the comments and obviously Twitter is not best place for having a nuanced discussion, so let me write explain where does it come from.

Before we start, I want to make a couple of things clear: contrary to most of my blogposts, this one is a hot take. I’m writing it as I sit on the airport and airplane back from the conference, trying to give some structure to the thoughts I have. I’m probably wrong about a lot of things. I’m no expert in compilation, I don’t understand how hardware operates, my quantum information knowledge is pretty rudimentary. I have not researched yet what are the alternatives, who else worked on some solutions to this and what that could possibly be.

But I am a software engineer (doing some research on the side), who tries to create better tools for people to interface with quantum computers. I think a lot about abstractions, interfaces, integrations and this is where I’m coming from – the “algorithms development”, “software tools” and “QC applications” part of the stack. I want to get this out while it’s still fresh in my mind to keep the momentum going – as I feel there’s a lot of momentum in the community to push this topic forward.

I cannot acknowledge all the people who contributed to this blogpost through the discussions, as I have talked with so many people about it. However, I need to make one exception – huge kudos to Yuval Sanders. We started talking about related issues months ago and all the discussions with him were eye-opening!

OK, after this overly lengthy introduction, let’s get into the details.

Problems with circuits

The problems stated below are in no particular order.

Problem 1 – expressivity

Let’s say I want to start my algorithm from a state that’s equal superposition of all possible states. How do I do that? I put Hadamard gates at the beginning of my circuit. Ok, now let’s say I want to change the basis in which I measure from Z to X¹. What do I do? I put Hadamard gates at the end of my circuit!

So when someone looks at my circuit and they see “H”, this could mean a lot of different things. The fact that you use Hadamards to create equal superposition, should be an implementation detail, not how you express your intent. You can argue that most of the time it’s obvious from the context what author meant. But that’s true only if you have significant amount of experience, and you can “read between the lines”. This definitely creates a barrier (not a huge one, but still) for new people and adds unnecessary cognitive load for everyone. In the end, my intention is not to use a Hadamard gate. My intention is to create equal superposition. Writing down a circuit with particular gates is not an effective way to communicate this intention.

Side note on cognitive load

If you’re not familiar with it, let me introduce you to the concept of “cognitive load”.

Cognitive load is basically the work that our brain needs to put in order to perform our task. Imagine having a conversation with someone while you are walking through an empty park on a sunny day. And now imagine having the same conversation in a crowded room, with loud music. One of the reason why it’s harder to have conversation in the latter situation is that your brain needs to ignore all the extra signals and focus only on what’s relevant for the conversation. All the noise adds the cognitive load.

Similarly in the data visualization – a good data visualization doesn’t have plenty of unnecessary details, it only has what’s necessary to convey the message. The more elements there are, the more our brain has to process. Which means that processing is slower and less efficient.

So in our case, the fact that someone needs to look at the circuit and figure out what we meant by the Hadamard gates in this specific context adds some unnecessary cognitive load.

Problem 2 – Circuits are too low level for many algorithms

When you want to tell microprocessor which diode to light when you hit a button, you can write this program using assembler. When you want to create a web form that takes some data, sends it to a server, stores in a database and sends an e-mail notification, you can write this in, let’s say, Django (Python).

Why?

Cause depending on the task at hand, it’s better to work at different layers of abstractions. Sure, your Python code will in the end get compiled to assembler, but you, as a web developer, can live your whole life and never think about this fact. Sure, you can try writing the whole web app in assembler – good luck! And what if your server breaks and you get a new one that uses different architecture? Rewriting the whole thing from scratch sounds fun, right?

What language we speak influences how we think – for better or worse. So back to quantum – thinking about algorithms in terms of circuits definitely is useful in some contexts, but is limiting in others. And actually, many people don’t think about algorithms in terms of circuits. They write equations, make operations on unitary matrices, use block diagrams. But often in the end, they need to express these ideas in terms of circuits, which as Yuval pointed out in this talk, is somewhat painful.

And the fact, that we don’t have a common way of expressing algorithms at higher level through software makes it harder to move field forward. Speaking from my own experience.

Problem 3 – Compilation

Let’s say I want to run QAOA. I can express QAOA with the following equations (details in my QAOA blogpost ):

\[| \gamma, \beta \rangle = U(H_B, \beta_p) U(H_C, \gamma_p) … U(H_B, \beta_1) U(H_C, \gamma_1) | s \rangle\]

Does this expresses exactly my intent? Yeah. Is this unambiguous? Sure.

Now I want to run it on some hardware. So I express it as a circuit – let’s say I use CNOTs, RXs, H and whatever else I need. I want to send this to hardware, but my hardware uses a different gate set. Ok, I can compile it to that gate set and we’re good to go.

So I have two steps:

“Mathematical formulation” -> “Abstract circuit” -> “Physical circuit”

Now what if we had some better representation?

We would get:

“Mathematical formulation” -> “Better representation” -> “Physical circuit”.

Still the same number of steps, so we’re kinda in the same place. But we already get some minor benefits – it’s way easier to do the first transition in the second case, as “better representation” is much closer to the “mathematical formulation”. And the other part is automated anyway.

But actually “better representation” might make the second transition easier as well. QAOA is pretty structured – I basically repeat the same operations over and over again, just with different parameters. In the “abstract circuit” representation I don’t have a way to express that, so if I have 1000 layers, I’ll create a very long circuit and them I’m forced to perform basicalyl the same compilation operations 1000 times. But if you have a better representation, you can do this better.

You can say that “better representation” could be simply “circuits with for loops” – I agree with that, this already would be an improvement in this case!

Another example, this time very close to my heart. In one project I’m working on, we’re building a pipeline that takes a “Quantum program”, compiles it to a set of fault tolerant operations and then performs resource estimation. Ok, so how does the process looks like in our case?

Logical circuit -> “Clifford + T” circuit -> ICM Circuit -> Graph state -> Some FTQC operations²

Details about this method has been described in this recent paper.

The point is, that (as far as I can tell), performing the first three transitions is not super important from the point of view of the algorithm. It’s just necessary evil, which is introduced because we express our algorithms as circuits.

Perhaps (pure speculation on my end) there is a more direct mapping from higher level algorithm primitives like “QFT” to the “Graph state”, which doesn’t require going through circuits. Maybe not, I have no idea. But isn’t it worth exploring such possibility more?³

Problem 4 – classical control flow

It’s really hard, perhaps even impossible, to express certain “classical flow” operations with circuits.Things like:

Repeat until success
Conditional execution based on mid-circuit measurements
For loops

Not to mention quantum error correction (QEC) instructions – but I leave this out as I would consider these “low level” – see section about QIR for more discussion.

As far as I remember QASM 3.0 gives you some of these things and I consider QASM 3.0 to be “extended circuits”, so I guess it kind of can be done, but I’m not sure to what extent.

Problem 5 – non-gate based computation

Another issue (brought to my attention by Jonathan Wurtz from QuEra, thanks man!) is that prevalence of circuits limits the usage of alternative approaches.

From what I understand about QuEra’s approach, they have analog machines. With these machines you can simulate the evolution of some Hamiltonian – which allows you to solve a wide variety of problems.

So you could implement QAOA on such machine – but the fact that you usually express them as circuits makes it harder. Sure, you can do some reverse-engineering, but it takes time and introduces friction. Having a better representation could makes it much easier to work with non-circuit-based platforms. (Probably missed out a lot of details, sorry for that! But I hope the point still holds.)

Another example – much more mundane, but affected me personally. Again – QAOA-centric. Most of the integrations with hardware/simulators we have at Zapata are circuit-centric. But there are very efficient ways of simulating QAOA (under certain conditions) that don’t require using circuits. For example, you can use analytical equations to simulate 1-layer QAOA for certain Hamiltonians. But I don’t do that, because the way I express QAOA ansatz is tied directly to circuits. And adding such option would be too much refactoring to be worth the effort for the project I’m working on.

Another paradigm that might suffer from circuits’ prevalence is Measurement-Based Quantum Computing (MBQC). MBQC is a very different way to think about quantum computation that I have not fully grasped yet, so I might be wrong here, but that’s my hunch.

Mid-blogpost remarks

Remark on QAOA

I’m using QAOA as example so much, for several reasons:

I’m very familiar with this algorithm
It has very good high-level representation and structure
It’s relatively simple, which makes discussion more approachable

I think that a lot of these points could be made with other algorithms – I don’t think that the fact that QAOA is variational algorithm has any importance here.

Remark on circuits usefulness

I don’t say the circuits are terrible abstraction that we should get rid off. No, they have their uses. I think the closer you’re to the hardware the more sense there is to use them. They are also very useful for optimizing performance of your algorithm if you want to run your algorithm in 2022.

My point is – they have limitations, let’s acknowledge them as a community and come up with a better abstractions that works for higher-level users as well.

Remark on breaking abstraction

In his presentation at IEEE Quantum Week 2022, Fred Chong mentioned that in their group, rather than building more abstractions, they are breaking the existing abstractions. I find their approach very appealing, but what I propose is building more abstractions. How do I reconcile this?

I think that breaking abstractions has two uses:

It allows you to build a better one
It allows you to increase efficiency of your program

In classical computing automated tool for compilation are so advanced that no human is able to beat it³. However, we’re not at this stage with QC and, at least for the next couple of years, researchers will have to do low-level tinkering with circuits in order to get best results. However, keep in mind, that not all the researchers work on algorithms that they want to run today – for them breaking the abstractions might not be as useful

Solutions

Ok, I ranted on circuits for a bit. So what’s my idea to make it better?

Well…

I don’t have a good idea!

I feel the pain, I see the problem, but I don’t have a solution. Even more – I’m pretty sure I don’t have the expertise to come up with such solution myself. But please bear with me for a couple minutes more, as while I don’t have solutions, I have some thoughts about how to get one..

Existing tools

I think there are many people who came up with solutions to tackle some of these problems. I have very vague idea about what they do and how they work, but from my brief interactions with them it seems to me that they extend / build on top of circuits and attempt to solve some of the issues listed above.

I might be wrong – one of these might have already solved all the issues! But I don’t know that and researching that would delay me releasing this by weeks, so I just expect other people to tell me what are the pros and cons of these solutions. Given my ignorance, I’ll just throw the names here without any commentary:

These are all very different, but I think they all have some elements that might be useful/inspiring for the end solution.

Quantum Intermediate Representation

There is this thing called Quantum Intermediate Representations (QIR), which looked very promising to me at first. It solves a lot of problems with compilation of quantum programs into instructions that are executable on hardware. It tackles issues with inter-platform compatibility and control flow – I’m pretty sure it has been designed to be QEC-compatible, at least to some extent.

However, from my superficial understanding of what QIR is, I think that it does’t actually solve the problems that I’m mostly concerned with – the problem of expressibility, of traversing layers of abstractions in the graph-state compilation process, or being good tool for thinking about the algorithms.

QIR is designed more to be a “machine-to-machine” representation, and not something that’s human readable.

QASM 3.0 on the other hand is much more human readable. But it’s still gates and circuits centric, which also doesn’t make it a good solution to the problems that I think about. QIR and QASM people – feel free to argue! As I said, this is all just my perspective.

Oh, and huge thanks to Cassandra Granade for the discussions on the topic and explaining me what QIR does a couple of times now ;)

Sidenote on naming

One of the issues I have with QIR is the matter of naming. As we can read in Wikipedia, “intermediate representation” (IR) is: “the data structure or code used internally by a compiler or virtual machine to represent source code”

So in my “Graph state compilation” example, my graph state is an IR. If you do Lattice Surgery, your time-space slices (or whatever that thing is called) is IR.

What QIR alliance is doing (unintentionally I guess) is owning the name “intermediate representation” for the IR that exists at the level of the stack that they have defined – which is somewhere between circuits and hardware. I might be totally wrong here and perhaps the examples I have given shouldn’t fall under “IR”. Again – people who are more experienced, please tell me!

Blocks

I have one idea for a representation which has the following pros:

It’s slightly higher level than circuits (so we don’t risk getting too far from current state of affairs ;) )
People are already using it
Is pretty flexible

It’s called “Using blocks that are higher level than gates”, or UBTAHLTG.

OMG, I just laughed on my own joke :D

How would such blocks look like?

Well, you could have a block called “prepare equal superposition” or “QFT” or “Grover’s oracle” and then you could construct your quantum program from these blocks. It’s basically how people write algorithms in their papers.

And if you want classical control flow, let’s express it as workflows (at Zapata we have love workflows ;) ). Or maybe computational graphs, whatever you want to call them. I’m not a computer scientists.

I don’t think it’s particularly revolutionary or novel, but I haven’t seen it widely used or expressed in software (though I bet people already did it). So maybe worth giving it some more attention and maybe coming up with some common conventions how to do this?

Here are some nice visualizations of how one can build circuits from blocks by Yidong Liao from UTS:

Note on standardization

In order for this to be useful and not introduce more friction, we would need it to be standardized to some level, we would need to have some common conventions. However, since we will still be experimenting with all this, we definitely don’t want to create poor standards and then force people to follow.

Not sure what’s a good way to deal with that.

This will be messy!

I don’t think anyone has a very good answer for the problems I stated. If that was the case, I think it would have already dominated the landscape⁴. So we will do, what software developers always do - create another competing standard!

But seriously – the process will be messy, there’s no doubt about it. But I think we can do it in a way that it’s not overly painful.

Let’s try not to compete. Let’s not try to force people into using this or that representation. Let’s not make incompatible standards and create technological lock-ins.

Instead let’s come to this with experimentation mindset. Let’s make it obvious to the users of our frameworks, that this feature is very experimental and it might change. Let’s make sure that they don’t get too attached and not build too much infrastructure around it. Let’s be nimble and collaborative. Let’s play with each other’s tools, take inspiration and ideas. Let’s be ready to ditch the projects that we’ve been working on and switch to something better than someone else designed.

That sounds idealistic, right? Is that possible – honestly I don’t think so. But I believe that if we keep such principles in mind, at least the whole process will be smoother.

How are we going to work on this?

First things first – I’m in no position to tell people what to do with all this. I just have some frustrations, talked with a bunch of people, listened to their frustrations and then decided to write it down. I just want to spur some discussion about the topic and hope that something will come out of this. I love my job, I love this community, but not enough to cut down my family and sleep time ;) Therefore this blogpost is not my declaration that I’ll come forward and lead the way.

I think we need to talk more – IEEE Quantum Week was a great place to start these discussions and I think we could use some other major conferences to advance it even further. If someone feels like organizing some virtual workshops on the topic – let me know, I’d be glad to participate.

Maybe more people should write what they think about it? Maybe even papers if someone feels like it? Maybe some conference talks, I don’t know.

Another extremely useful thing – if you know how this kind of “experimenting with new abstractions and driving community consensus” has been done in other industries, please share this knowledge with others! I think we, as a quantum community, sometimes try to reinvent the wheel, while there are already battle tested solutions.

Also, I’d be really glad if we could have some discussions in the comment section under this blogpost – I’ve read some really good discussion under some Scott Aaronson blogposts, so I think this is not a bad way to have a discussion.

Speaking of Scott Aaronson – if anyone feels like asking people who have been thinking about foundational issues in quantum information for decades already, that would be great. I bet they have plenty of good thoughts on the topic.

Final remarks

I think this blogpost is good way to start discussion, but will get outdated pretty fast, as I will be getting feedback – I expect ~50% of what I stated here to be at least somewhat misguided and/or inaccurate. So I think that instead of trying to keep it updated, I’ll just write a proper version when I get enough feedback to feel confident about doing it.

If you’d like to read more of my “raw thoughts” like this, please let me know. As anyone who ever talked with me would know, I have plenty of thoughts on multiple topics (especially quantum software), so perhaps it’s worth start sharing them more publicly.

Please comment, please share, please argue! For me the best outcome would be if someone proved to me that circuit is the ultimate best abstraction for QC, cause then we have one less problem to worry about and I can get back to doing different things ;)

And don’t forget to subscribe to the newsletter here if you’d like to stay up to date with my writing and other projects.

Have a nice day!

Michał

P.S. It’s kind of refreshing feeling to know that I can write a whole blogpost in 4 hours, then spend extra 2 hours reading and editing (instead of usual 30+). And I don’t have to give it to at least 5 people to proof-read and ask Rafał to do all the editing and correction. Wow!

Footnotes:

I think that actually just to change the base you need only RY($\frac{\pi}{2}$), cause Hadamard adds some extra rotation to the mix. But I also think that people sometimes use Hadamard to change the basis, so feel free to correct me if I got something wrong. ↩
This is still at the early stage of development and I still don’t understand all the steps very well – that’s where the vague “Some FTQC operations” is coming from. ↩
I think Jim Keller said that in one of the interviews with Lex Fridman. Absolutely excellent interviews, highly recommend listening to them: link 1, link 2). ↩ ↩²
There’s also a good chance that it was just so ahead of times that the world was not ready for it and we need to revisit this idea. ↩

Make a great first impression with your quantum computing resume

Mon, 02 May 2022 12:30:00 +0000

Dear Reader,

In the last couple of years I’ve been mentoring, educating and supporting a lot of people who were at the start of their journey with quantum computing. Apart from that, I’ve been helping with hiring for various positions at Zapata Computing. In the process I’ve reviewed hundreds of CVs and given feedback on tens of them and decided that maybe instead of giving people the same advice over and over, I’ll just write a blogpost about it.

I think 90% of the advice is universal regardless of the field, but I tried to add some that is relevant for the new fields with a highly scientific vibe, like quantum computing.

I also gave a presentation at the Careers in Quantum conference in 2021 on the topic of getting a job in QC. I guess since you’re reading this article, that presentation will also be highly helpful for you.

And last, but not least, keep in mind that everything I say here is my perspective. I tried to make it universal, it got reviewed by several people with different points of view, but there is probably still some bias left.

So here we go!

What does the hiring process look like?

Before we get into the details of the CV itself, it’s also important to understand how the hiring process itself works (especially if you don’t have much experience).

So here are a couple of rules that I didn’t realize before I got involved into hiring and that made all my future hiring processes waaaaay less stressful:

There are people on the other side – they make mistakes, they forget stuff. But they also have empathy and might bend rules a little bit in certain circumstances (e.g. you missed the deadline for application by one day because you got sick)
Hiring may be one of several competing priorities – imagine a team that started the hiring process but then they discovered a critical bug in a project for a customer and had to spend 2 weeks fixing it. No surprise your hiring process got delayed.
They have limited time to process the applications – imagine getting over 200 applications for an internship position (I’ve been there!). Do you think anyone will spend 5 minutes per application (over 16 hours in total) to read the whole CV line by line? Or will they rather spend 30 seconds per application and then focus on the several really interesting ones?
Processes might look totally different from company to company, but also from team to team.
Different positions might have very different timelines – some positions need to be filled as soon a possible, for some others the team will keep waiting (even months) for someone with specific expertise to come up.
Applying through the website is only one of many channels through which a company learns about the candidates – I personally never got hired just through an “application form”, it always involved some forms of personal recommendations.
The hiring process is not always static – sometimes things change while you’re in the hiring process, be it the team needs, hiring managers or some other circumstances. Don’t take it as a bad sign!

To be honest – this (especially points 2 & 3) is not necessarily how it should look like in the real world. But often (especially at startups), people wear multiple hats, there’s a lot of hiring and things are always in flux. I guess it’s just one of those moments where reality sucks…

How to plan writing

Before you start writing your CV, you should have a plan. Here are some tips on the preparation part:

Every CV I have written in the last 5 years has been written with a specific position in mind. Read the job description, highlight key words, make sure you know exactly what the company is looking for.
Do your research about the company. Check out the website, search for interviews, see what recent projects they have done. If you can target a specific team, that’s even better.
See if you know anyone inside the company and you could ask them about the position. Maybe you met at a conference last year, maybe you have a common friend?
Just search “How to write a CV” – most of the generic advice is actually valuable and totally makes sense!

Writing tips

You did your research, you know what they’re looking for. Now, let’s get down to writing.

Be concise

Keep your CV short. It forces you to be concise, to focus only on the relevant info. Do you really think anyone will read 5 pages of your CV in detail? No? So why don’t you save some time for the person on the other side and just put in what counts and not all your highschool awards or list of all the conferences where you presented in the last decade. You can put links to your GitHub, Google Scholar, personal website with an extended version of the CV. If your short CV will catch recruiter’s attention, then they’ll definitely want to dig in before proceeding with the process. If it doesn’t, then the long version probably also wouldn’t.

I personally always make mine one page long. I’m not saying this is the solution for every person, but in most cases I’ve seen, people tend to put too much irrelevant information into their CV and limiting yourself to one page is a good way to focus on what’s important. For senior candidates, 2 pages is still fine (I guess I’m not at that level of seniority yet ;) ).

Be specific

Focus on relevant info. You did your research, you know what they’re looking for. Go through all the items you highlighted earlier and make sure you include something that addresses it in your CV (if you meet the criteria, of course).

Are they looking for a “team player”? Make sure to make it clear that in the last project you worked as a part of a group. Do they say they’re looking for “self-starters”? Make sure to include info about the initiative you started at your university. There’s not a single word about figure skating? Well, perhaps you don’t need to spend half a page listing all the awards you won as a figure-skater, one line will suffice.

When you’re done writing, go through every single item on your CV and ask yourself – is this something that the recruiter will care about? Should I keep it or remove it? I’ve seen people including passport numbers or high-school awards they got 5 years ago, why would anyone care about that?

A couple of extra tips:

Put the month and year in for dates (not just the year).
If a role is a contract or side project, make note of that next to the job title so it doesn’t look like you are job hopping.

Be careful

Put only things that you’re comfortable talking about. Let’s say you’re in the middle of a project. It’s relevant for the job, but you have only started to set things up and you don’t have any significant results to talk about. Would you feel comfortable if they ask you about it during the interview? If so, sure, put it there. If not, please don’t.

For another example: my company, Zapata, has done a lot of research in the field of variational quantum algorithms. A friend wanted to apply to Zapata and he sent me his CV for review. I noticed “variational algorithms” in the “Expert” section. I told him: “Saying that you’re an expert in VQA when you apply to Zapata is kind of risky ;)”. He moved it to the “Intermediate” section. Be aware of the context!

If you want to add a skill that is new to you and relevant to the role, put it in the skills section under the title “Learning”. This says you have interest in the skills needed for the role, even if not an expert yet and it means the interviewer will have more realistic expectations when asking about it.

Taking a “shotgun” approach to listing skills and experience can seriously backfire. Your designated hiring manager may believe—usually after talking to you—that you haven’t cared to distinguish your “actual” skills from those you might conceivably pick up, and will make you a very blurry and uncertain candidate.

Be careful 2

Make sure you don’t include the info you shouldn’t include. In some countries or some companies, there might be anti-bias policies and for example including a photo might work against you.

Be honest

While I admit it is the status quo to embellish and sometimes slightly exaggerate the truth on one’s CV, absolutely do not lie. I had a situation where a friend reached out to me asking about a person that did a project with me. The problem was that they actually didn’t, but they had that in their CV. We had an initial conversation, we laid out the plan for the project, but I never heard from him afterwards. I don’t have to tell you they didn’t get the job.

I really mean it, don’t lie.

Be accurate

Sure, everyone might have a typo in their CV, but you really don’t want to show that you’re sloppy and so lazy that you haven’t even checked your CV against some online grammar&style checker (e.g. Grammarly).

I also try to pay attention to the “brand names”. The official spelling of the “PennyLane” framework is, well, “PennyLane” and not “Penny Lane”, “penny lane” or “Penny-lane”. Sure it’s not the most important thing in the world and I guess most people won’t notice, but some do. It might also matter more in certain roles that include content creation, (e.g. “technical writer”) or very detail-oriented ones, (e.g. in quality assurance).

Be expressive

Text formatting is an extremely useful tool that will make your CV effective. Use bullet points, colors, bolds and italics, font sizes, all the tools at your disposal, to make it easy to find certain information. Use it strategically, help the recruiter to find the info they’re looking for right away. Make sure that the font has high contrast compared to the white background; for example, do not use a gray font.

Don’t overdo it – you don’t want your CV to stand out visually (unless you really know what you’re doing!), but rather make it easier to navigate.

I learned a lot about how people process visual information from the book (and blog) “Storytelling with Data” by Cole Nussbaumer Knaflic. It’s mostly about data visualization, but many points are useful also in this context as well.

Additional tips

I don’t understand why people don’t include their thesis’ supervisor’s name in the CV. I seriously doubt this could work against them, but if the person reading your CV knows the person, it could work in their favor. This really might be a dealmaker!
Don’t include names of your references in your CV. If the hiring manager needs to do a reference call, they will ask you for the contact info. Some people might get upset to have their name “out there”.
Use links – if you write about a project and it’s on GitHub, link it in your CV.
The job posting will soon disappear from the website, so save it to a pdf. You can keep that for future reference.
You might have done some really amazing projects, but if all I see is a project title I will never know why it’s interesting.
Many candidates have lost a job due to a bad Facebook account and did not even realize it.

QC specific tips

To make this section useful, I’ll explicitly limit myself to “entry-level positions in quantum computing companies”.

For the most part, the characteristics a hiring manager wants to see is unambiguous technical capacity. Hiring managers usually believe technically competent individuals can be appropriately trained in the multidisciplinary field of QC, and thus such managers will be looking for evidence of that on your CV.
QC-related knowledge and skills are not necessarily the most important things for the recruiting team. It should be pretty clear from the job posting. Some QC companies already have many experts on board and they actually need some other skills.
Highlighting tutorial-level projects is not very impressive. I would prefer to see a simple “Basic familiarity with qiskit” rather than a whole entry which describes that you’ve implemented the “Grover search algorithm for 5 qubits”, go to GitHub and see 30 lines of codes and one plot there.
Demonstration of skills adjacent to QC, such as in mathematics, science, computing, and/or academic research will typically be a better indicator and more valuable space on your CV than simple forays into QC.
It is better to tell a hiring manager you have either no QC knowledge, or pop-sci level, than to try to “talk the talk” and blunder (especially if you don’t even know you’re blundering).
Highlight any interesting projects that you did and if you did something novel/particularly interesting, make it clear!
Relevant online courses may be worth mentioning if other demonstrated experience is lacking, but “relevant” is key word here, and don’t expect that an “intro level QC course” will impress anyone.
It’s a small world – if someone from the field mentored you or you did a project together, please mention their name, there’s a chance that the person recruiting you knows them (if you expect they would give you a good reference of course ;)).
Mentioning your active participation in the QC community is valuable if kept brief; there is no need to spend half a page listing all your contributions, hackathons, meetups, small-scale presentations, etc.

After you’re done

Ok, you spent the whole afternoon polishing your CV, now it’s time to apply, right?

No.

Now it’s time to do two more things.

First, ask someone to review it, possibly someone more experienced than you. They’ll probably immediately spot some issues that would be hard for you to find. Remember to send them the job posting alongside the CV, so they have all the context they need. Second, get some rest, and come back to it a day or two later. Read it again and you’ll be surprised how many things you’ll find to improve.

Closing notes

Thanks for reading, I hope you found it helpful! If you did, you might find some other resources on my blog helpful as well, so feel free to explore :) As always – consider subscribing to the newsletter: link

Also, just a couple of days ago Olivia Lanes (IBM) posted her thoughts on the topic of breaking into quantum workforce, it might be interesting for you as well!

And huge thanks to everyone who helped with writing this post. They contributed a lot of insight:

Claudia Taylor – People Operations Manager at Zapata
Christi Amend – Senior Technical Recruiter at Lambda, previously at D-Wave.
Peter Johnson – Lead Research Scientist at Zapata
Robert Smith – Chief of Quantum Software at HRL Laboratories
Rafał Ociepa – Head of Product at Droplabs and my loyal editor!

Have a nice day!

Michał

VQE - challenges and state of research

Mon, 10 Jan 2022 12:30:00 +0000

Dear Reader,

Last time we talked about challenges associated with Variational Quantum Algorithms in general and today we’ll focus more specifically on Variational Quantum Eigensolver (VQE). All of the things we’ve covered previously are relevant for VQE as well, but here we’ll focus on challenges and progress that are more specific for VQE.

If you don’t remember exactly how VQE works, you can refresh your memory with the first article in the series – “VQE explained”, which is also a good place to start if you’re new here.

One more thing – while I was working on this article a new preprint came out on arxiv by Tilly et al. It is a really great piece of work and it made my life much easier. Therefore I consider this article a light-weight review of the current state of VQE, but if you’d prefer an actual deep scientific dive, that’s the place to go!

Without further ado, let’s start with…

Ansatz design

Ansatz design is a big part of ongoing research for VQE. However, I won’t be going into more details in this article, for a couple of reasons:

I covered ansatz design in the previous part.
Reviewing various ansatzes would require some introduction to quantum chemistry, which is beyond the scope of this piece.

If anyone is interested, you can find a great review in Fedorov et al. or in more details in Anand et al. And if you need some introduction to quantum chemistry, the first part of this review by Cao et al is a decent starter.

Hamiltonian construction

This is a topic that requires way more quantum chemistry background than I have. I found section 3 and 4 of Tilly et al. covers this topic way better than I would, so if you’re looking for a good reference, that’s the place. It contains explanations of concepts such as the Jordan-Wigner or Bravyi-Kitaev transformations, which allow us to translate Hamiltonians from the realm of quantum chemistry to quantum computing and which are definitely some terms I’ve come across a lot but did not understand for quite a long time.

It’s also worth checking out this tutorial to the Fermi-Hubbard model by Warren Alphonso, it also explains some of these concepts very well.

Ok, after these two disappointingly short sections, let’s get into concepts which do not require background in quantum chemistry!

Measurement problem

VQE is basically an estimation problem – given a parameterized quantum circuit you want to estimate the expectation value of an operator (Hamiltonian) with certain precision. Two big issues are how to design the circuit and how to get the right parameters, but we’ve talked about them a lot in the previous article. Now let’s talk about “certain precision” – we’ll work on a concrete example of a $CO_2$ molecule. To be clear, this problem is associated with every “cost function evaluation” in VQE that we do while optimizing parameters, not just the final result.

A standard accuracy that we desire in quantum chemistry is called “chemical accuracy” and is equal to 1kcal/mol¹, which is roughly equal to 1.6 mHa²). But for this exampe we want to be extra safe – in the end, these quantum devices are far from perfect, so let’s aim for an accuracy of $\epsilon = 0.5 mHa$. Fortunately, the relation between the number of measurements we need to do and the target accuracy is fairly simple: $M = \frac{K}{\epsilon^2}$. $K$ is a constant that depends on a molecule of interest, the estimation strategy used³ and certain other assumptions about the problem. In Gonthier et al they calculated that for $CO_2$ it’s $K=8000$. After substituting values in the equation above it turns out we need 32 billions measurements to properly estimate the expectation value of interest. This number seems high, but to give you a better sense of how much it actually is, this is equivalent to (given some reasonable assumptions described in Gonthier et al ) roughly 39 days of calculations.

Let’s stop here for a moment to appreciate that.

We need to run a quantum computer, for 39 days, non stop, to get a single estimation of energy⁴.

And you know how many energy estimations you need to perform to actually find good parameters for VQE if we run an optimization loop? I tried it for a simple $H_2$ molecule with much more optimistic assumptions and got 87, but it can easily increase to thousands.

Therefore, one of the biggest challenges for VQE is how to reduce this number of measurements and fortunately, there are a couple of methods to do this. I described some of them in the previous post, like “interpolating algorithms”, and below you can find the description of how grouping and measurements allocation works. They tackle different components in the “overall VQA structure” (see VQA post), so some of these methods can be used in conjunction.

Grouping

VQE is all about finding the lowest eigenvalue of a given Hamiltonian, which is expressed as a sum of Pauli terms. For each term we need to run a separate circuit and perform multiple measurements. Then we combine the results of all the runs and we calculate the energy of a given state based on that.

However, there’s a big problem with this naive way of using VQE. Let’s say our Hamiltonian looks like this: $X_0 + Y_1 + Z_2$. It consists of three terms and in the most basic implementation we would just run a separate circuit for each term. However, each term affects a different qubit, and hence, you can run just one circuit and measure all of them at the same time (we say that these terms are co-measurable).

Let’s consider a slightly more complicated example:

\[Z_0 \cdot X_1 + Y_1 \cdot X_2 + X_2 \cdot X_3 + X_0 + Z_3\]

There are a couple of ways to gather these terms in co-measurable groups, one being:

Group 1: $Z_0 \cdot X_1 + Z_3$
Group 2: $Y_1 \cdot X_2 + X_0$
Group 3: $X_2 \cdot X_3$

And another being:

Group 1: $Z_0 \cdot X_1 + X_2 \cdot X_3$
Group 2: $Y_1 \cdot X_2 + X_0 + Z_3$

Obviously the second allows us to perform a smaller number of evaluations to get the same result.

It turns out that performing grouping efficiently is already a pretty hard problem – there has been a lot of research in recent years to find better algorithms to do this. You can find a summary of these methods in Table 1 of Huggins et al. Some key takeaways from this table for our discussion:

Number of groups depends polynomially on the number of qubits⁵. While “polynomial scaling” usually means “good” in algorithms, $N^4$ might be actually pretty brutal in practice.
There are different tradeoffs that we need to take into account when choosing grouping methods. Some work best with certain QPU topologies, some others increase the number of gates, etc.
Smaller number of groups does not necessarily imply a smaller total number of overall measurements! More groups might actually allow us to get higher precision by achieving better energy estimation per group with the same number of measurements⁶.

Section 5 of Tilly et al. provides an introduction into some of the grouping methods, so if this topic is of interest for you, that’s where you should go.

Measurements allocation

Let’s say we have our groups now and we want to actually run the circuits and get some measurements. Should we just go ahead and do that? Well, not necessarily. Let’s say we have a Hamiltonian that looks like this:

\[H = H_1 + H_2 + H_3 = 5 Z_0 + 3 Z_1 + 2 Z_0 \cdot Z_1\]

And a circuit which creates a state:

\[| \psi \rangle = ( \cos{(\frac{\pi}{6})} |00 \rangle + \sin{(\frac{\pi}{6})} |10 \rangle)\]

By calculating expectation values by hand, we can see that

$\langle H_1 \rangle = 5 \langle Z_0 \rangle = 5 \cdot 0.5 = 2.5$
$\langle H_2 \rangle = 3 \langle Z_1 \rangle = 3 \cdot 1 = 3$
$\langle H_3 \rangle = 2 \langle Z_0 \cdot Z_1 \rangle = 2 \cdot 0.5 = 1$
$\langle H \rangle = 6.5$
Looks easy, right?

But now let’s see what happens if we try to measure these on a QPU⁷, with 100 shots for each term⁸.

$\langle H_1 \rangle = 5 \cdot 0.66 = 3.3$
$\langle H_2 \rangle = 3 \cdot 1.0 = 3$
$\langle H_3 \rangle = 2 \cdot 0.58 = 1.16$
$\langle H \rangle = 7.46$

Ok, let’s try once again, now with 1000 shots:

$\langle H_1 \rangle = 5 \cdot 0.488 = 2.44$
$\langle H_2 \rangle = 3 \cdot 1.0 = 3$
$\langle H_3 \rangle = 2 \cdot 0.504 = 1.008$
$\langle H \rangle = 6.448$

As we can see, the estimates we got are not exact and they depend on the number of shots. So we can increase the accuracy by increasing the number of shots, problem solved, right? Well, not really, as when we increase the number of shots, we also increase the time of running calculations.

Can we be smarter about it? Absolutely…

One can use a fixed total number of shots (budget) and allocate it among various groups. So let’s say we have 300 shots in our budget, how should we allocate it? The first approach is to do a uniform allocation, i.e. 100 shots for each operator. This is what we did in the first example. But we can do better than this. We know that the operators have weights 5, 3 and 2. So it would make sense to put most shots from our budget towards the first operator and least shots towards the last one. Let’s say we do that proportionally – all weights add up to 10, so we use $\frac{5}{10}$ shots for $H_1$ (150), $\frac{3}{10}$ for $H_2$ (90) and $\frac{2}{10}$ for $H_3$ (60). What did we get?

$\langle H_1 \rangle = 5 \cdot 0.53 = 2.65$
$\langle H_2 \rangle = 3 \cdot 1.0 = 3$
$\langle H_3 \rangle = 2 \cdot 0.66 = 1.32$
$\langle H \rangle = 6.97$

This result is better from what we got from just using 100 shots per operator. But this could be a random fluke, so in order to evaluate that, we should calculate the standard deviation (std) of our final energies. So after repeating my experiment 10000 times, it turns out that for uniform shot allocation, std is 0.469 and for proportional shot allocation it’s 0.420.

You might wonder – proportional allocation is definitely better than uniform, but what is the optimal allocation strategy? Well, as always, the answer is not simple. It will generally depend on the exact grouping method used, and getting a perfect answer is generally not possible: indeed, the number of shots necessary depends on the standard deviation of each individual term, which itself depends on the current wavefunction on the quantum computer. In some cases it is possible to mathematically solve for the optimal allocation by making some assumptions about these standard deviations, for more details see Rubin et al. section 5.1. Arrasmith et al. is also a good reference for this problem.

What we did so far was allocation of shots for a single evaluation of energy. But what if we wanted to have a shot budget for the whole optimization process? Perhaps at the beginning of the optimization we don’t need as much precision as towards the end? One approach to this has been proposed in Cade et al. (but also described very well in Bonet-Monroig et al. ), which authors call “3-stage-approach”. It works by defining a shot budget for the whole optimization process and later dividing the optimization in 3 stages. As an example, they use 100, 1000 and 10000 samples in stages 1, 2 and 3 accordingly. However, different phases have assigned different numbers of energy evaluations. The ratio they proposed is 10:3:1, so for the first phase they use $\frac{10}{10+3+1}$ of all energy evaluations, in the second $\frac{3}{14}$ and just $\frac{1}{14}$ in the last.

This allows for much more efficient usage of the available resources, as you can see in the plot below (it’s, fig 6 from Cade et al.).

This is just one way to approach this problem, you can find others in Gu et al. or Arrasmith et al.

VQE beyond ground states

VQE is usually used for finding the ground state of a given Hamiltonian. However, it could also be used to solve other problems, such as:

Finding excited states of the system
Calculating vibrational spectrum of a molecule

Finding excited states of a system

In many cases we’re interested in finding the excited states of a given system, not just the ground state. For example, in order to get information about the color of a material we need to know what the energy difference between the ground stare and first excited state of the molecule is. One approach to do this has been described in McClean et al. and Colless et al. It basically boils down to the following steps:

Run a regular VQE in order to find the ground state of the system.
Once the algorithm has converged, modify the Hamiltonian in such a way that it contains information about excited states.
Measure new Hamiltonian.
Perform some classical postprocessing of the results.
Voila!

There are many other variations of VQE, if this is of interest to you I recommend section 9 of Tilly et al.

Calculating vibrational modes

Another interesting property that we might want to learn is associated with the vibrations existing in the molecule. What is it about? Well, atoms in the molecules are not rigid, they are in constant motion in respect to each other and this movement, the vibrations, can affect the properties of the molecule in non-trivial ways. This is important for topics such as astrochemistry or modeling fuel combustion, but also particularly useful for a class of molecules that have certain structures.

In principle, we can use the old good VQE to solve it – we just need the to use a different Hamiltonian, which describes those vibrational modes. However, since this problem is different from the electronic structure problem that we usually solve, there are somewhat different considerations, e.g. we use different mappings to construct the Hamiltonian or we need to pay more attention to the excited states.

If you would like to learn more about this topic, I talked about it with Nicolas Sawaya, research scientists working at Intel in my podcast and here you can find his paper where he describes these ideas in more details.

Outside of quantum chemistry

In principle you can use VQE for any situation where you have a matrix and you want to learn what its lowest eigenvalue is.

One example can be using VQE for solving combinatorial optimization problems. Usually, we think about using QAOA for such problems, but QAOA also takes a Hamiltonian as a problem, so we could use VQE to find its ground state as well. If you’d like to better understand the difference, I have covered the difference between these two methods in my “QAOA explained” article. An example of using VQE for combinatorial optimization problems can be found e.g.: in Liu et al.

Apart from that, I have not encountered any particularly exciting or promising use cases for VQE outside of chemistry, so I’m not going to talk about it too much. However, if you know one, please leave me a comment under this article and I will be happy to include it :)

Conclusion

Thank you for reading!

As it turns out, getting to the forefront of VQE actually requires more quantum chemistry background than I expected, hence article ended up being shorter than I expected.

If you’d like to get deeper into the topic, follow the references I left throughout the text and make sure to spend some time with Tilly et al!

I wanted to thank people who helped me review the draft!

Rafał Ociepa
Nicolas Sawaya
Jérôme Gonthier
Boniface Yogendran
Peter Johnson

If you don’t want to miss the next (and the last!) part of the series on VQAs, which will be a deep dive into QAOA, sign up for the newsletter. And since QAOA is kind of my thing, expect this to be a really deep dive – I can’t wait to write it!

edit: you can find it here) !

Have a nice day!

Michał

P.S. The graphics I used as a “thumbnail” on the main page of my blog comes from the Wombo project. It’s amazing!

Footnotes:

Why does anyone use this particular number? As it gives you order-of-magnitude correct answers to reactions rates, based on Arrhenius equation at room temperature. ↩
mHa is a unit of energy used in quantum chemistry. ↩
For example it might change depending on whether you group measurements or not. ↩
Nowadays you need to recalibrate your device every couple of hours in order to make sure its performance doesn’t degregate, source. ↩
It’s actually in the number of spin orbitals, which corresponds to the number of qubits in the most commonly used Jordan-Wigner transform. ↩
For more details see Huggins et al, and section 5.3 from Tilly et al., or section V of Yen et al. ↩
Well, to be honest with you, I have used a simulator ;) ↩
We often say “shots” instead of “measurements” in QC. ↩

VQAs - challenges and state of research

Thu, 27 May 2021 12:30:00 +0000

Dear Reader,

This is the fourth part of my series about Variational Quantum Algorithms (VQAs). In previous parts we learned how these algorithms work in theory, now it’s time to learn more about some challenges, current research, and practical considerations about them.

In this article, we’ll focus on the general issues with running VQAs on quantum computers, regardless of their specific structure. We’ll go into more detail about challenges unique (or at least more characteristic) for VQE and QAOA in the next two posts.

If you haven’t read the previous parts or you’re not familiar with these algorithms, here you can find previous parts of this series:

Also, Here’s a list of the concepts that we talked about in previous posts. If you’re not sure what they mean, please stop for a moment to refresh your memory, as I won’t be explaining them here again.

Ansatz (VQE article, “What the hell is Ansatz?”)
Hamiltonian (VQE article, “What VQE does”)
Expectation values (VQE article, “The variational principle”)
Hyperparameters (VQA article, “Basic setup”)

While writing this article I heavily relied on two excellent review papers: from Alan Aspuru-Guzik group of University of Toronto and a big collaboration of various institutions. You can find a lot more details there!

Let’s begin!

No matter what algorithm you want to run on the NISQ devices, you need to deal with the following issues:

Noise
Connectivity
Size of the device
Limited gate-set

Noise types

Understanding how noise and error impact quantum computation is an entire subfield known as quantum characterization, verification and validation (QCVV). We’ll stick to just a cursory description of a few important concepts.

On a physical device, two important concepts involving error are:

Decoherence—unwanted interaction between the qubits and their environment that causes the quantum state of the qubits to lose its purity
Control error—physical operations (e.g. laser pulses) that are not exactly as intended, causing the actual quantum gates to differ from the target quantum gates

In practice, these are quite intertwined and difficult to separate. Generally, they lead to three types of error in a quantum computation:

Coherent error—during a quantum circuit the quantum state is shifted to a different quantum state
Stochastic error—during a quantum circuit the quantum state becomes an average of different quantum states
Measurement error—you might have a perfect quantum computer with zero noise and then at the end of the circuit, your measurement procedure might assign an incorrect state when you measure it

Coherent and stochastic error differ in how they cause overall error in a quantum circuit to accrue. Coherent error accrues less favorably in that the quantum state can continue to be shifted in the wrong direction. With stochastic error there can be some canceling out of the errors so that on average they leave you close to the intended state.

If you’d like to learn more, see section 8.3 of Nielsen and Chuang. For those looking for a deeper rabbit hole, here are some more papers: Kueng et al., Zhang et al., Bravyi or Geller and Sun.

To give you some ideas about how it looks like on real devices we have today, let’s take a look at the specs of the device from ETH Zurich used in this paper.

As we can see, all the qubits have very different characteristics. There’s a lot of data here, so let’s focus on the following values:

T1 and T2—they roughly define the lifetime of a qubit. T1 defines how long does it take for the qubit to go from $\mid 1 \rangle$ to $\mid 0 \rangle$ and T2 measures how quickly qubit loses its phase (see section 1.1 here).
Readout assignment probability—this basically defines the measurement error. As you can see it’s different for states $\mid 0 \rangle$ and $\mid 1 \rangle$ (you can disregard state $\mid 2 \rangle$ ).
Gate errors—the percentage values next to nodes (green) indicate one-qubit errors and next to edges the two-qubit errors (blue). This basically tells you what’s the probability that a given gate won’t do what it’s supposed to.
Gate speed—how long it takes to execute one gate.

Ok, what does it all mean? Let’s use the most optimistic values for simplicity—lifetime of the qubit equal to 27.2$\mu s$, gate errors 0.18% and 1.7%, and gate speed 50ns (see Fig 1c from the paper).

This means that we can apply at most $\dfrac{24.5 \mu s}{50 ns} \approx 500$ gates to still be able to get reasonable results. What does it look like if we take gate errors into account? The probability that the result you get for a single qubit is correct is equal to (1 - gate error)^(number of gates). So if you want to be 90% sure that you got the right result, you can run 50 gates. If 80% is enough that’s about 123 gates. What about 2-qubit gates? Well, you can use only 6 of them for the 90% case and 13 for the 80% case.

To make things even worse, once you make a measurement, some of the measurements will be wrong anyway. I couldn’t find the number in this paper, but for Google’s Sycamore chip, readout error was 3.8% (see Fig 2.).

Btw. I highly recommend the paper that I took the data from, it shows you what’s the state-of-the-art implementation of QAOA on a real device. And here’s another good example from Google.

There’s also statistical uncertainty (sometimes also called “sampling noise”)—this is the error that we introduce into our estimates by the fact that we cannot directly measure the wavefunction, we need to sample from it. So having 100 measurements gives you results with more uncertainty than having 10,000 measurements. We’ll probably talk more about how to deal with that in the next article.

A good example of how the noise affects result are the plots of the optimization landscapes of 1 layer QAOA which came from Google’s Sycamore chip (Fig 3 in this paper):

One way to deal with these issues (at least some of them) is to use Quantum Error Correction (QEC). QEC is a set of techniques that allow you to correct some errors that can happen in your circuit. If you‘ve ever heard about the distinction between “physical” and “logical” qubits, then you might know that by “logical” people usually mean “perfect, error-corrected qubits”. Once we have such qubits, we will be in the realm of Fault-Tolerant Quantum Computing (FTQC) The problem is that in order to implement one error-corrected qubit you have to use a LOT of physical qubits (which also depends on the level and type of errors), as we encode one logical qubit in an entangled state shared by multiple physical qubits. We can design this state in such a way that the quantum information is protected against different types of noise. But since in this article we’re talking about variational algorithms and the NISQ era, we won’t actually go into this, if you’re interested check out chapter 10 from Nielsen and Chuang.

Another, quite straightforward, way to deal with some of these issues is to simply run short circuits. The fewer gates you have, the lower the chance something will go wrong. Obviously, improving the hardware also helps (or, as it turns out, improving control software responsible for gates, as shown here). But let’s get into some more algorithmic techniques.

Error mitigation

Instead of correcting the errors and getting perfect results, we can try to mitigate the errors. There are many interesting techniques (see here for a good review), here I’ll describe one of them to give you a general idea of how it can be achieved. It’s important to mention that these methods allow us to better estimate the expectation values of some operators. This means that we’ll be talking about getting certain real numbers with a specific precision, not about getting the correct set of 0s and 1s.

One of the methods is called “Zero Noise Extrapolation” (source). The main idea is that if we just run our circuit, it will be affected by a certain base level of noise. Our goal would be to know the result for the “zero noise” case, but we can’t just fix the hardware so that it doesn’t have any noise. However, we can artificially increase (scale) the level of noise. So we’ll run our circuit a couple of times, with different levels of noise, and then we’ll extrapolate it to see what happens for the “zero noise” case.

Here’s a picture that shows the idea:

How do you artificially increase the noise? Well, there are a couple of methods to do that, one of them involves simply duplicating gates—we replace gate G by (G, G’, G), where by G’ I mean the inverse of G.

There are other error mitigation techniques, but in general, they involve running several modified versions of the original circuit and performing some post-processing to get the value we’re interested in.

If you’d like to use error mitigation techniques, there’s an open-source python library called mitiq developed by folks from Unitary Fund. You can learn more about ZNE and other methods, as well as about mitiq from this talk by Ryan LaRose (which is also the source of the plot you see above).

There’s one more important caveat here – what I described is mitigation by “classical postprocessing”. There’s another way to achieve error mitigation by performing certain actions during the execution of the circuit which counteract the noise.

Compilation

Well… If noise itself wasn’t bad enough, there are other issues which make its existence even worse. It’s the device connectivity (i.e. which qubits are directly connected, so you can use a two-qubit gate between them) and gate set (i.e. which gates you can directly execute on the hardware)¹

How do you deal with these? Two basic methods are compilation and ansatz design, and in this section, we’ll talk about the first of these. To be honest—I know very little about compilation, so this section definitely doesn’t do justice to the topic, though I think it’s important to include it for the sake of completeness.

What is compilation? It’s transforming one quantum circuit into another one that does exactly the same thing.

Usually, we do compilation for the following reasons (in no particular order):

Our circuit doesn’t map well on the hardware architecture (dealing with connectivity)
Our circuit uses gates that are not directly implemented on the device (dealing with the native gate set)
We want to minimize the number of gates (reducing the impact of noise). Usually, we care mostly about 2-qubit gates, as they are much more noisy than 1-qubit gates.

There are different approaches to compilation, here I present three that I’m aware of:

Rule-based—we define a set of rules (e.g. how to decompose a gate into a set of other gates) that we then simply apply to the circuit.
We treat circuits as some mathematical structure and perform some mathmagic to simplify it, for example using ZX calculus. Don’t ask me for any more details, I’ve personally chosen to just think about it as mathmagic (though to be honest I’ve heard this review is a decent intro to ZX calculus, I simply never got to reading it. There’s also this open source package.).
Machine Learning—well, you can also just throw some machine learning at the problem, as they did in Harrigan et al.

If anyone is interested in the topic this article might be helpful. Another important theoretical result to mention is the Solovay-Kitaev theorem—it basically says that we can approximately compile any unitary operation into a limited set of gates quite efficiently (with some caveats, of course, more on wiki).

That’s it for now, if I learn more about the topic I’ll revisit and improve this part. Let’s now get into the topic much closer to my heart. Namely…

Optimization

Ok, we’ve covered some general, hardware-related issues. Now it’s time to talk about the more algorithmic part. One of the central components of VQAs is the optimization loop and there’s indeed a lot of research on this topic. So let’s see what are some of the main challenges involved:

Barren plateaus

Imagine you want to find the lowest point in some area. How would you do that? Well, you can just look around, follow the slope and you’ll eventually get somewhere. Doesn’t sound like the best possible strategy—if you’re in the mountains you’ll soon find some valley, though not necessarily the lowest/deepest one. But at least you’re getting somewhere. Do you know what’s a nightmare scenario in such a case?

A huge desert.

You’re not able to see anything but flat sand all the way to the horizon and the landscape constantly changes as the wind reshapes the dunes.

What’s the only chance you have of actually finding what you’re looking for? Start from a point that’s so close to the valley you’re looking for that you just can’t miss it. What’s another name for a landscape like this?

A barren plateau.

In 2018 Jarrod McClean et al. pointed out that there are two big problems with training variational quantum circuits.

The first is that you can’t just run a single circuit and learn what the value of the gradient is (we’ve discussed it in the previous VQA post). You need to repeat a certain procedure several times and the more times you do it, the better accuracy you get. This is not a big problem if your gradient is huge; let’s say it has a value of 9001. You just repeat the procedure several times and you know the ballpark. But what if your gradient has a value of 0.00001? Well, you have to run many many more circuits (for those interested—in the best case it scales as $O(1/ \epsilon)$, where $\epsilon$ is desired accuracy.)²

The second is, that for random quantum circuits the gradient is really small in most places except for some small area where it’s not. And the chance that it’s arbitrarily close to zero for a random point grows exponentially with the number of qubits and number of parameters (see this PennyLane tutorial for more context).

Ok, now let’s put it together in plain English. In most places, the gradient is close to 0 and from the practical perspective, there’s a limit to the precision up to which you can estimate it. So basically unless you start close to good parameters, you have no clue how to tweak your parameters to get anything reasonable. And the more qubits or gates you have, the worse it gets.

I also like the plot below (source: Cerezo et al.) which visualizes the problem. It shows how the landscape changes when we increase number of variables in the cost function (from 4 (blue) to 24 (orange)).

As a side note, I find this problem shows quite well one of the problems with the state of quantum computing research. As long as you’re running small simulations, this effect is too small to be noticed. So some previous small experiments might be fundamentally flawed because if you tried to scale them up, you would hit the barren plateau problem. On the other hand, there might be other problems that we’ll notice only when we’ll get to hundreds of qubits. These are exciting times to be working on QC!

Dealing with barren plateaus

Not surprisingly, these findings resulted in quite some stir in the community. People started coming up with various methods to solve this issue and here we’ll go through a couple of them. Let’s look at the two common approaches for dealing with this problem.

The first way is to simply initialize your parameters close enough to the minimum so that your optimizer can find its way to the minimum. This might sound like a no-brainer—sure we want to have a good way of initializing the parameters, right? Actually, it’s not that obvious, as in classical machine learning, it usually is not that big of a problem and you can get away with initializing parameters randomly. So how do you choose a reasonable parameter initialization? There are several methods to do that, one of them is the so-called “layer by layer” (LBL) training³

Many ansatzes we use consist of layers. Basically, all the layers are identical and (at least in theory), the more layers you add, the more powerful your circuit is (QAOA is a good example). So here the idea is that we start from training our algorithm for one layer. Since barren plateaus depend on both the number of qubits and the depth of the circuit, it should allow us to avoid them. Then, once the 1st layer is optimized, we treat it as fixed and train parameters for the second layer. Once its training is finished, we proceed with the next one until we have all the layers we wanted. Now we have some initial guesses of the parameters and we proceed to train more than one layer at a time e.g. 25% of them.

So at first, we try to avoid barren plateaus by training only a handful of parameters at the time. And then, we try to avoid them by starting from a point that is already a pretty good guess.

The second idea is about restricting the parameter space—if you can design your ansatz specifically for a given problem, it might be less expressible (we’ll talk about expressibility in a moment), but as long as it can find the solution to your problem, it doesn’t really matter.

Just to put things in perspective, since the initial paper published in March 2018, I’ve counted 18 papers with the words “barren plateaus” in the title and the phrase was cited 263 times according to Google Scholar. If this problem sounds interesting to you, some good papers to read would be those about what are the sources plateaus (entanglement and noise), or some mathematical ways to avoid them.

Choice of optimization methods

A question that I sometimes hear is “are there optimizers that are specific for quantum computing”? In principle no, as you can treat the calculation of the cost function in the variational loop as a black box, and therefore you can use any optimization method for that. However, there are certain challenges associated with our particular black box that might make some optimizers a much better fit than the others.

So the first challenge is that in general, we consider the time spent running algorithms on a quantum chip much more expensive (money-wise) than on a classical one. Therefore, since we use it exclusively for calculating the value of the cost function, evaluating the cost function is the most expensive part of the algorithm. Thus, it is something we want to do as little as we can get away with (isn’t it somewhat ironic, that when we run calculations of a quantum computer, we want to use it as little as possible?). The practical meaning of this is that we want to use optimizers that can work well while making a relatively small number of evaluations.

The second challenge is the probabilistic nature of the cost function evaluation. In order to deal with it, you need to repeat your circuit more times to have better accuracy. Or using an optimizer, which works well with some level of noise/uncertainty.

The third challenge is the existence of noise. Noise might have different effects on the landscape of the cost function. One is “flattening of the landscape,” another might be the existence of some artifacts. Both these effects are visible in the plot we’ve QAOA landscapes we’ve seen before.

Last, but not least, it’s extremely hard to study the behavior of the optimizers. They often rely on hyperparameters (e.g.: step size in gradient descent), their behavior might be different for different problems. This is a problem not only for QC, this is the same for classical optimization problems or regular Machine Learning. Also, the cost of implementing and checking the performance of various optimizers is really high, so researchers usually either decide to use one that worked for them in the past or one that is commonly used or perhaps check a couple of them and pick the one that looks reasonable. Yet another issue is that sometimes these methods are studied without the noise (where they work well), but they don’t perform that well in the presence of noise.

My plan was to follow this section with a selection of some widely used optimizers, and explanations why some of them are widely used. But after digging into the literature, I wasn’t able to come up with anything satisfactory. It basically looks that right now we have little to no idea why certain optimizers work while others don’t. So if you’re interested in this topic, I recommend the following papers: Sung et al. and Lavrijsen et al.. Excellent work which shows how hard it is to analyze these and how much we still need to learn.

Ansatz design

We’ve already mentioned ansatzes in the previous section, but let’s now make them our main focus. Ansatz design is an active field of research, some of my favorite papers are those by Sukin Sim and other folks from Zapata, Lena Funcke et al. and J. Lee et al.. Since I like to be practical, let’s look at this from a practical perspective:

How can you tell whether an ansatz is a good one?
How to design a good ansatz?

Is my ansatz any good?

In the NISQ world, when you have an ansatz, you want to ask yourself two questions:

How powerful is my ansatz?
How much does it cost to use it?

What does powerful mean in this context? One component is its expressibility—i.e. whether we can create an arbitrary state with it. The best illustration of this concept I know is the picture below (source Sim et al.). It shows how changing the circuit changes the amount of the space that we can cover.

Another useful metric is the entangling capability of an ansatz. We want the ansatz to be able to produce highly entangled states, as the more entanglement there is, the more “quantum” it is and potentially more useful.

These metrics are the best we have, but unfortunately, they are not really very good. Expressibility might not be a good metric for large circuits as more expressive circuits might be also more prone to barren plateaus or have more parameters and be harder to optimize. Entangling capability—well, creating circuits that are hard to simulate just for its own sake doesn’t make much sense.

Therefore, we can use these two metrics as something that can help us rule out bad ansatzes, but not necessarily find the best ones. Some further reading: Haug et al. and Cerezo et al.

When it comes to cost, typical metrics to measure the cost are:

Circuit depth—the more shallow the circuit, the better chance that noise won’t destroy our quantum state.
Circuit connectivity—since on many NISQ devices we cannot directly connect arbitrary qubits, it might be beneficial to have an ansatz which only requires connectivity between nearest neighbors.⁴
Number of parameters—fewer parameters mean an easier job for optimization.⁵
Number of two-qubit gates—usually two-qubit gates are much more noisy than one-qubit gates, so this number is often used to compare different circuits.
Gate types—it’s a little bit more indirect, but if we have an ansatz which uses gates that are not available on our hardware, we will need to decompose gates, which increases circuit depth.

How to design a good ansatz

Now we want to have an ansatz for which expressibility and entangling capabilities are high, while we keep all the associated costs to a minimum, right?

Easier said than done :) How do you come up with the idea for the ansatz in the first place? At the moment there are two main schools: problem-motivated and hardware-motivated ansatz design.

To design a problem-motivated ansatz, you do things like:

Thinking hard about the problem you want to solve
Analyzing whether there is any structure in the problem you can exploit
Reading existing literature on “classical” (meaning not QC) methods for solving this problem to get inspired.

To design a hardware-motivated ansatz, you do things like:

Memorizing technical specs of the device you have
Figuring out how to make maximally expressive ansatz given the hardware constraints
Reading existing literature on this type of hardware to find some tricks you can exploit or traps you can fall into.

As always, both methods have some pros and cons that I’ve summarized below, and combining both of them probably is the best solution.

Problem-motivated

Pros:

Can exploit problem structure
Can be used with different devices
Doesn’t require intricate knowledge about the hardware

Cons:

Might not be implementable on specific hardware
Might perform poor on real hardware while working perfectly in theory
Probably will work only for a narrow class of problems

Hardware-motivated

Pros:

Allows to squeeze the most out of the device
Doesn’t require intricate knowledge about the problem domain
Can be used for solving multiple problems

Cons:

Might not take advantage of the problem’s structure
Is probably useful only for a very specific device

One consequence of coming from the problem-focused approach is that you don’t necessarily want to have the maximally expressible ansatz. While such an ansatz would by definition cover your solution, it will also cover all the solutions that you might a priori know are useless. Often we have some knowledge about the problem and we know that a certain family of states does not contain the ground state, so we can make our ansatz simpler (and hence lower the cost) by designing it in a way that excludes such states.

How to get a good ansatz without designing it?

There’s yet another method for finding a good ansatz—let the algorithm figure it out. To do that, we use what are called “adaptive” algorithms. The main idea is that we modify not only the parameters of the circuit, but also the structure of the circuit itself during the optimization.

One example of such a method and the first such algorithm proposed is a method called ADAPT-VQE. Here’s a general description of how it works:

Define an “operator pool”—this basically contains the bricks that you’ll be building your algorithm from.
Create some initial reference state as the first iteration of your ansatz.
Calculate the gradient of the expectation value for each operator in the pool using your ansatz.
Add the operator with the biggest gradient to the ansatz (along with a new variational parameter).
Run “regular VQE” with this ansatz to optimize all the parameters of the ansatz.
Go to step 3.

For a more detailed description please see Grimsley et al.).

Another example of an adaptive method is PECT, which I have mentioned in the previous article .

Here are some comments about these methods:

These algorithms are usually more difficult to implement on the classical side, as they involve more than just taking a parametrized circuit and adjusting the parameters, but also changing its structure.
It’s not obvious whether such an approach actually yields better results or produces them faster. There are two effects that are at play—on one hand, the algorithm should need more time than a conventional one because it needs to find the correct structure of the ansatz and optimize its parameters at the same time (in point 5 of ADAPT-VQE we’re running a full, regular VQE!). On the other hand, doing both at the same time makes the optimization process actually simpler as it doesn’t introduce (or gets rid of) parameters that are useless. In principle it should find better solutions, however, it might take longer—it’s hard to say before actually running it for a specific problem.
These algorithms seem especially promising for NISQ devices, as they produce ansatzes that are shallower than those designed by hand (and hence there’s less room for noise), but also they naturally find circuits that take into account all the quirks of a specific device. For example, in ADAPT-VQE you can create an operator pool in such a way that it leads to hardware-efficient ansatzes (see Tang et al. ).

If you want to learn more about ADAPT-VQE and the problem of ansatz design in general, Sophia Economou (one of the authors of ADAPT-VQE) gave an excellent 25-minute talk about these during one of Quantum Research Seminar Toronto (QRST).

As a side note, this approach reminds me of a NEAT (Neuroevolution of Augmenting Topologies) algorithm used for classical neural networks. You can find an excellent video showing how a NEAT algorithm learns to play Mario.

Interpolating algorithms

The approach which makes me particularly excited is something I’ll call “interpolating algorithms.”⁶ What do we mean by “interpolating”? The fact that the performance of these algorithms can interpolate between that of near-term and far-term algorithms. You can adjust some hyperparameters of the algorithm depending on what hardware you’re running on, so no matter what stage of development of quantum hardware we’re currently at (from now to perfect qubits), you can find hyperparameters that will allow you to actually run the algorithm within the limitations of the hardware and squeeze most out of it.

Imagine you have circuit A that allows you to estimate the ground state of some Hamiltonian. If you want to estimate it to precision $\epsilon$, you would need to run circuit A $N_A=\frac{1}{\epsilon^2}$ times. You also have circuit B, that allows you to get the same precision, but you only need to run it $N_B = log(\frac{1}{\epsilon})$ times. However, circuit B is $\frac{1}{\epsilon}$ times longer and hence not very practical for the devices we have today. But what if we had some way to interpolate between these two approaches so that we would have a parameter that makes the circuit longer, but also decreases the number of samples needed?

Let’s see what it could look like in practice. Let’s say $\epsilon=10^{-3}$. This means we need to run circuit A 1,000,000 times and each execution of circuit A takes 1ms. So the total runtime will be 1,000s. For circuit B we need to run it log(1000) times, which is just 3 times (sic!), though each execution takes 1 second. Hence we would get our result in just 3 seconds. Unfortunately, as we have seen earlier, our circuit probably won’t be able to run for as long as 1 second anytime soon. However, this class of algorithms gives us a way to construct such a circuit that it requires less measurements but its execution time still fits our hardware.

While this explanation is oversimplified , going into more details is, again, way beyond the scope of this article. If you’d like to learn more, three examples of similar approach are “alpha-VQE”, “Power Law Amplitude Estimation” and “Bayesian Inference with Engineered Likelihood Functions for Robust Amplitude Estimation” by my colleagues from Zapata . (I strongly recommend watching this 3.5-minute video explaining the gist of it).

Other issues

This article has been quite dense, so here I wanted to just point to some other final issues that are prevalent in contemporary research, without spending too much time on any of them:

Lack of common benchmarks and standardization

As you could see from the section about optimizers, it’s really hard to benchmark certain solutions. It’s not only extremely costly to compare multiple methods, but it’s also really hard to design such an experiment in a way that makes the comparison fair and broadly useful.

On top of that, as can be expected for a discipline at such an early stage, we lack standardization. This is healthy, as it allows for more experimentation and exploration, but it makes it much harder to compare results, as you basically never compare apples to apples.

We have no idea what we’re doing

The truth is that QC is a totally new paradigm of computation that we don’t comprehend. I‘ve had the opportunity to talk with some excellent researchers in the field and while their level of understanding and intuition about these matters is far beyond my reach, they’re quite open about the fact that we all just started scratching the surface. There are some fundamental questions that no one knows the answers to, which is both a challenge and a source of excitement.

Scaling for bigger devices

In most of our research, we’re limited in what we can analyze by the size of the devices we’re able to simulate with computers (rarely beyond 30 qubits). Bigger devices are extremely scarce—there is literally a handful of them in the world—so we have very little understanding of how these methods will scale beyond 50 qubits. And while some results seem independent of size or we have some theory that explains how they will behave, for many we don’t. And right now there’s no other way of knowing other than building bigger devices and trying them out.

Closing notes

Thank you for going through this whole article! If this was of interest for you, you’ll definitely like the next part, where I focused on VQE. The best way not to miss any future articles is to subscribe to the newsletter.

So just in case you have missed them, I recommend checking out:

My podcast.
QOSF monthly challenges—especially if you’d like to hone both your coding skills and learn some interesting QC concepts.

Last, but not least, I wanted to thank all the people that helped me write this article. And this time that was more people than usually:

Pierre-Luc Dallaire-Demers for being an infinite well of knowledge and references. His help reduces the complexity of looking for references from $O(n)$ (searching through $n$ papers) to $O(1)$ (asking one Pierre-Luc).
Rafał Ociepa for all editing and stylechecks.
Alba Cervera-Lierta, Ntwali Bashige and Peter Johnson for reviewing the whole thing with their eagle eyes and making sure I’m not saying something stupid.
Ahmed Darwish and Alex Juda also for reviewing the whole thing and being my test “target audience”.
Sophia Economou and Sukin Sim for reviewing specific sections associated with their research.

Have a nice day!

Michał

Footnotes:

For explanation why these are problematic please see VQA blogpost. ↩
Numbers here are totally fake, I’m just making a point. ↩
Another example: E. Grant et al. ↩
This depends on the hardware type, as it’s a much bigger issue for superconducting qubits rather than ion traps. ↩
Though there are some counterarguments, see Kim et al or Lee et al. ↩
There’s no proper name for this class of algorithms in the literature yet. ↩

Musty Thoughts

Quantum Software Newsletter

Context

Who is this for?

What to expect?

What’s next?

IEEE Quantum Week 2024

Need for better abstraction hierarchy

Standardization

Darpa QB program

QRE workshops

How to make things happen

Closing

QRE workshops summary

Grand Challenges

Travis Humble

Wim van Dam

Panel

Machinery

Sam Jacques

Daniel Litinski

Thomas Alexander

Tools

Summary

Closing notes

Random acts of kindness

QAOA - challenges and state of research

QAOA vs QAOA

Problem-related issues

Problem formulation

Constraints

Encoding

Parameter concentration

Modified cost functions

Other ansatzes

Warm-start QAOA

Quantum Alternating Operator Ansatz

Implementation tradeoffs

Parameter initialization

Closing notes

Perfect Quantum Resource Estimation Software

What is QRE and why is it hard?

Main challenges

Many assumptions

Science is changing

Ill-defined abstractions

Target group

Decision makers

Application scientists / algorithm researchers

Resource-estimation-related researchers

Hardware providers

Ideal resource estimation software

Modularity

Future compilation chain

Well defined abstraction layers

Multiple entrypoints

High quality results.

Scalability

Visualization

Hosting

Open-source

Well documented

Well tested

BenchQ

Closing notes

Let's move beyond circuits

Let’s move beyond circuits!

Problems with circuits

Problem 1 – expressivity

Side note on cognitive load

Problem 2 – Circuits are too low level for many algorithms

Problem 3 – Compilation

Problem 4 – classical control flow

Problem 5 – non-gate based computation

Mid-blogpost remarks

Remark on QAOA

Remark on circuits usefulness

Remark on breaking abstraction

Solutions

Existing tools