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
Doing simulations with SPAM errors introduces a significant time overhead dependent on the samples_per_run argument, which was intended to give extra statistics (almost) for free.
The reason is that detection errors (false positives and false negatives) cycle on the sampled bitstrings and randomly flip the bits. In the following simple example execution time increases tenfold when increasing samples_per_run from 10 to 1000:
A first issue is that reducing the epsilon and epsilon_prime parameters to zero does not get rid of the overhead.
Secondly, the time overhead could probably be improved following a suggestion of @Louis-PaulHenry.
As @sebgrijalva pointed out, reducing the evaluation times helps dramatically, so it could be used as a workaround.
The text was updated successfully, but these errors were encountered:
Doing simulations with SPAM errors introduces a significant time overhead dependent on the
samples_per_run
argument, which was intended to give extra statistics (almost) for free.The reason is that detection errors (false positives and false negatives) cycle on the sampled bitstrings and randomly flip the bits. In the following simple example execution time increases tenfold when increasing
samples_per_run
from 10 to 1000:A first issue is that reducing the
epsilon
andepsilon_prime
parameters to zero does not get rid of the overhead.Secondly, the time overhead could probably be improved following a suggestion of @Louis-PaulHenry.
As @sebgrijalva pointed out, reducing the evaluation times helps dramatically, so it could be used as a workaround.
The text was updated successfully, but these errors were encountered: