Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of compute algorithm from arxiv:2101.12223 #1273

Open
wants to merge 46 commits into
base: main
Choose a base branch
from

Conversation

or1426
Copy link
Contributor

@or1426 or1426 commented Jun 17, 2021

Summary

The paper https://arxiv.org/abs/2101.12223 contains two algorithms for finding Born rule probabilities of Clifford+phase gate circuits. This pull request contains the compute algorithm (and everything it depends on).

This is not suitable to be merged currently. Documentation, tests and are missing, and there are some problems (see below), but I open it to get some feedback.

Details and comments

In addition to the compute algorithm a new save instruction is added to the quantumcircuit class. The instruction
save_specific_probability(outcomes, measured_qubits) to save the Born rule probability of a particular measurement outcome of a computational basis measurement applied to a subset of the qubits.

Example usage

qc.save_specific_probability([0,1,0], [0,1,2]) # save the probability of the obtaining the outcome (0,1,0) when measuring qubits (0,1,0)

qc.save_specific_probability([0,1], [5,1]) # save the probability of the obtaining the outcome (0,1) when measuring qubits 5 and 1

It would also be reasonable to add support for this instruction to other simulators - e.g. the statevector simulator.

Known problems

  1. Currently the CliffPhaseCompute::State class does not correctly report it's memory usage
  2. Currently the Compute algorithm implementation is not parallel
  3. The Compute algorithm can also deal with expectation values, this should also be implemented

@hhorii
Copy link
Collaborator

hhorii commented Aug 16, 2021

I think extending save_probability() (by adding new keyword argument states) is better than adding a new function save_specific_probability().

@or1426
Copy link
Contributor Author

or1426 commented Aug 17, 2021

I think extending save_probability() (by adding new keyword argument states) is better than adding a new function save_specific_probability().

I don’t disagree with this but it requires a bit of thinking about. One of the functionalities of the new save_specific_probability() method is the ability to specify a measurement on an arbitrary subset of qubits. For example you can ask it for the probability of outcome 01 when you measure the first and third qubits of a five qubit state.

We want to add this for two reasons, firstly it might be useful to people, and secondly one of the nice features of the algorithms from this paper is that they can do this without excessive overhead (compute doesn’t need to marginalise the probability distribution or anything like that). If you try to implement this functionality for (for example) the statevector simulator you have to do an exponential (in the number of qubits) amount of work adding up the probabilities to get the outcome you want on the qubits you want.

@hhorii
Copy link
Collaborator

hhorii commented Aug 17, 2021

the statevector simulator you have to do an exponential (in the number of qubits) amount of work adding up the probabilities to get the outcome you want on the qubits you want.

That's true. Maybe, with a naive implementation, statevector gets all the probability amplitudes and then take specified amplitudes. Though its cost can be huge, we will implement it in statevector, too.

I'm thinking API. save_probabilities and save_probabilities_dict have an argument qubits to filter outcome probabilities. I guess that states is a kind of similar argument.

Any comments? > @chriseclectic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants