-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Support dynamic circuit in BackendEstimator #9700
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
Support dynamic circuit in BackendEstimator #9700
Conversation
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5821920454
💛 - Coveralls |
Actually, it is not clear to me why |
@garrison Thanks. The intent of this relaxed condition is to support circuits with auxiliary qubits like the test example https://github.com/Qiskit/qiskit-terra/pull/9700/files#diff-ec629567417753086ce09aba87c8dc9f34ab946d903fe809200ba692a7ed8e2dR364 |
I see. But in that example, why not just specify the observable as Otherwise, you presumably need some logic to determine what is an "auxiliary" qubit or not. For instance, is it considered an auxiliary qubit if it contains a Another way of phrasing my question: With this PR, you could pass the same circuit multiple times along with observables of different numbers of qubits. How are these different observables expected to be handled within an Estimator implementation? |
You are right. Certainly there is no way to distinguish if they are auxiliary qubits or not, so it may be a good idea to have the user explicitly enter I. |
One or more of the the following people are requested to review this:
|
I come up with an idea to make a separate classical register for measurements. Could you take a look at it, @ikkoham? |
[Discussion] Separate measurement registers for BackendEstimator
I initially made this PR with the intention of supporting dynamic circuits, but I noticed that it is bug for circuits with classical registers, even if they are not dynamic. I hope it will be merged as soon as possible. |
OK. I review it asap |
When I ran the test locally, I found the following warning in
|
How is the final measurement treated?
|
minor update of tests. ikkoham#79 |
Discussing internally. |
Revise tests and fix typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Support dynamic circuit in Estimator * fix lint * revert the validation condition * fix test * add reno * separate measurements * lint * add test and bug fix reno * fix reno * revise tests and fix typo --------- Co-authored-by: Takashi Imamichi <[email protected]> (cherry picked from commit 660448c)
* Support dynamic circuit in Estimator * fix lint * revert the validation condition * fix test * add reno * separate measurements * lint * add test and bug fix reno * fix reno * revise tests and fix typo --------- Co-authored-by: Takashi Imamichi <[email protected]>
* Support dynamic circuit in Estimator * fix lint * revert the validation condition * fix test * add reno * separate measurements * lint * add test and bug fix reno * fix reno * revise tests and fix typo --------- Co-authored-by: Takashi Imamichi <[email protected]> (cherry picked from commit 660448c) Co-authored-by: Ikko Hamamura <[email protected]> Co-authored-by: Takashi Imamichi <[email protected]> Co-authored-by: Jake Lishman <[email protected]>
Summary
This PR makes BackendEstimator supports dynamic circuit.
Details and comments