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

Factor out XEB fidelity estimator out of XEB experiment code #2113

Open
viathor opened this issue Sep 16, 2019 · 3 comments
Open

Factor out XEB fidelity estimator out of XEB experiment code #2113

viathor opened this issue Sep 16, 2019 · 3 comments
Assignees
Labels
area/experiments kind/health For CI/testing/release process/refactoring/technical debt items

Comments

@viathor
Copy link
Collaborator

viathor commented Sep 16, 2019

XEB experiment code is monolithic. In particular, it tightly couples generation of random circuits and fidelity estimation. The latter is potentially useful on its own (e.g. when RQCs have been generated and executed offline), so should be factored out for re-use.

Also, there is more than one formula for estimating fidelity, e.g. on a few qubits one can compute cross-entropies directly while on many qubits one has to resort to formulas based on some assumptions about the shape of the output distribution. Therefore, it makes sense to implement fidelity estimation separate from RQC generation and overall XEB orchestration.

@mpharrigan
Copy link
Collaborator

See quantumlib/ReCirq#85

@MichaelBroughton
Copy link
Collaborator

Is this still an issue @viathor, @mpharrigan ? Is there a plan here ?

@augustehirth
Copy link
Collaborator

augustehirth commented Mar 23, 2022

Misunderstood the question the first time...

Noted in the existing XEB tutorials are separate library call wrappers from cirq.experiments.random_quantum_circuit_generation, cirq.experiments.xeb_sampling, and cirq.experiments.xeb_fitting which seem to already divide generation and fidelity estimation.

However, these functions seem to be designed to be pipelined: the input data structures to each subsequent function is expected to be the output of the previous. It may be good to make these interface data structures simpler in order to make each function/component more usable in other situations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/experiments kind/health For CI/testing/release process/refactoring/technical debt items
Projects
Status: No status
Development

No branches or pull requests

7 participants