-
Notifications
You must be signed in to change notification settings - Fork 131
Description
Informations
- Qiskit Experiments version: 0.12.0
- Python version: 3.13
- Operating system: Fedora Linux 42
What is the current behavior?
When using StandardRB
, the analysis will fail if more than 10,000 Cliffords are used in the experiment.
Steps to reproduce the problem
from qiskit_aer import AerSimulator
from qiskit_aer.noise import NoiseModel, depolarizing_error
from qiskit_experiments.library import StandardRB
noise_model = NoiseModel()
noise_model.add_all_qubit_quantum_error(depolarizing_error(5e-3, 1), ["sx", "x"])
noise_model.add_all_qubit_quantum_error(depolarizing_error(0, 1), ["rz"])
backend = AerSimulator(noise_model=noise_model)
expt = StandardRB((0,), lengths=[1, 100, 10_001], backend=backend, num_samples=1, seed=1010)
expdata = expt.run().block_for_results()
This produces a figure like this:

expdata.analysis_errors()
is an empty string and no messages are written to stdout or stderr.
What is the expected behavior?
The analysis should succeed and produce a fit on the plot and associated analysis results. Besides that, if the analysis does fail, the failure should be reported to the user.
Suggested solutions
Digging into the code, I find that the analysis failure comes from RuntimeError: Invalid exponent, max exponent is 10000
issued by asteval.astutils.safe_pow
. That limit was added long ago to asteval in lmfit/asteval#17 with little explanation. I believe the motivation of the limit is that asteval
could be operating on Python int
s which are unbounded and so could grow exponentially in memory footprint. When working numpy, numeric types have fixed memory sizes and so there is no danger of using too much memory. The maximum exponent is set here and has not changed since it was added 10 years ago.
Possible solutions:
- Monkey patch
asteval.astutils.MAX_EXPONENT = max_cliff + 1
inRBAnalysis._initialize
. To be polite, we should set the value back to what it was but there isn't a good place to do that (we might need to override_run_analysis
and callsuper()._run_analysis()
in a try/except to make sure it always set back. Maybe we should not worry about it and just leave it at the higher value. If going with this approach, we could perhaps ask upstreamasteval
if there could be a more official way to changeMAX_EXPONENT
. - Change the fit model expression. I think changing the model to
(alpha ** (x / 10)) ** 10
would avoid the problem. Does the model expression get used in documentation anywhere that would make this awkward? From a quick check, it looks like we just recreate the expression in TeX syntax for the documentation any way. - Do something else to break out of the lmfit/asteval limitation?