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

Error Generator Propagation Module v2.0 Tracking #539

Open
6 tasks
coreyostrove opened this issue Feb 17, 2025 · 0 comments
Open
6 tasks

Error Generator Propagation Module v2.0 Tracking #539

coreyostrove opened this issue Feb 17, 2025 · 0 comments
Assignees
Labels
enhancement Request for a new feature or a change to an existing feature
Milestone

Comments

@coreyostrove
Copy link
Contributor

coreyostrove commented Feb 17, 2025

This issue is intended to serve as a tracker for ideas and updates related to a future version 2.0 of the error generator propagation module.

  • Bulk methods for probability and pauli expectation value corrections: There is currently a lot of redundant computation when computing multiple output probability or pauli expecation value corrections. E.g. instantiating a fresh stim.TableauSimulator and computing the tableau inverse to set its state is a non-trivial fraction of the overall runtime. By reworking the implementation we should be able to amortize such costs over multiple corrections reducing overhead.
  • Bugfix for random error generators: Figure out a corrected construction scheme for building CP-constrained error generators w/o needing both C and A errors to appear in conjunction.
  • Refactor composition code: The error generator composition code is currently ~6000 lines. There is a whole bunch of structure here which we should be able to leverage to cut this down by at least a half.
  • Refactor label propagation out of the LocalStimErrorgenLabel class into a separate function in errorgenproptools.
  • Refactor LocalStimErrorgenLabel into two classes. One which contains only the metadata needed for Markovian models and a child class with additional metadata relevant for non-Markovian applications. This should reduce the overhead of object instantiation (a significant portion of the overall runtime).
  • More flexible iterative BCH options. There's no reason we can use mixed BCH orders across the iterative compositions, and there may be interesting performance vs. accuracy tradeoffs to explore.
@coreyostrove coreyostrove added the enhancement Request for a new feature or a change to an existing feature label Feb 17, 2025
@coreyostrove coreyostrove added this to the 0.9.15+ milestone Feb 17, 2025
@coreyostrove coreyostrove self-assigned this Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Request for a new feature or a change to an existing feature
Projects
None yet
Development

No branches or pull requests

1 participant