-
Notifications
You must be signed in to change notification settings - Fork 57
Magnus Expansions, Better Tableau Inference, and Errorgens on Paulis #625
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
Conversation
Add an initial implementation of the analytic Magnus expansion for up to second order and switch to using this as the default choice for doing BCH for EOC error generators.
Add a numerical implementation of the magnus expansion up to second order for testing infrastructure purposes.
Add stim conversions for the 24 single-qubit clifford gates numbered C0-C24.
Add in an implementation of the third-order Magnus expansion.
Add correct weighting to boundaries of the discretized Magnus integrals to account for time-ordering.
Update the numerical magnus expansion testing code to include the third-order Magnus expansion.
Add unit tests for the new analytical magnus expansion implementation.
Generalize the method for converting a circuit to a stim Tableau to allow automatic inference of the mapping from pyGSTi labels to stim qubit labels for most standard cases. Also adds ability to specify a custom conversion behavior for cases where this doesn't work. Plus some new unit tests for the conversion methods.
New function for analytically computing the action of an elementary error generator on a give Pauli. Returns the resulting pauli along with the corresponding weight. Also included is a numerical implementation used as part of new unit tests.
Fix a unit tests with incorrect indentation and which used the wrong method for a couple conversions.
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.
A few ease of development items which may be nice to have.
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.
I have a request that in principle could apply everywhere, but I specifically ask for this file: can you use a space for the first after "#
" when using in-line comments?
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.
To be clear, you're simply asking that every comment of the form #<some text>
-> # <some text>
, correct?
If so, then sure I can do that, but it is going to utterly annihilate the diff (there are ~650 such comments in this file). So I will make that the very last thing I do on the branch just before merging after this is approved.
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.
Yup! That's what I'm hoping for.
Add in plumbing for the additional kwargs used to control the behavior of the pyGSTi circuit to stim Tableau conversion process.
Add requested type annotations of the stim conversion methods and for the new functions in errgenproptools.
@nkoskelo or @rileyjmurray: How do I avoid this linting error for these type annotations? https://github.com/sandialabs/pyGSTi/actions/runs/16983348064/job/48147611727#step:11:28 |
Streamline the tests for the error generator propagation module by reducing the number of test cases for a number of the tests and replacing exhaustive testing with randomized selections.
By adding a conditional import of stim when type checking.
Update: I added a conditional import to the top of the file and that resolved this.
Where the type checking flag is provided by the typing module. |
Resolve a circular import error from new type annotation.
Update the inline comment styling per Riley's request.
This PR adds three new features/updates to the error generator propagation module:
stim.Tableau
has been extended to support automatic inference for the vast majority of use cases. For tricky or edge cases there are now options for manually controlling the label mapping behavior.