You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.LocalStimErrorgenLabel
class into a separate function inerrorgenproptools
.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).The text was updated successfully, but these errors were encountered: