Pith. sign in

REVIEW 4 major objections 4 minor 35 references

Distinguishing Quantum Software Bugs from Hardware Noise: A Statistical Approach

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read A shift in most probable outputs means bug, not noise.

desk verdict Useful heuristic, but the 'every bug shifts MPS' assumption is unproved and likely false for small or unmeasured bugs; still merits a referee. read the letter →

arxiv 2507.20475 v1 pith:KNCKMCYF submitted 2025-07-28 cs.SE quant-ph

classification cs.SEquant-ph
keywords quantumsoftwaredebuggingNISQnoisemostprobablestatesbias-entropymodeldepolarizingmutationtestingGrover'salgorithmDeutsch-Jozsa-Simonalgorithms
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out a diagnostic rule for the 'output dilemma' of NISQ programs: when a run gives unexpected results, tell whether the cause is a software bug or hardware noise. Its claim is that the two causes leave different statistical fingerprints: bugs change which measurement outcomes are most probable, while depolarizing noise below a circuit-specific threshold only spreads probability mass away from those outcomes without changing which set is on top. The proposed Bias-Entropy Model therefore compares the measured Most Probable States (MPS) with the known Desired States (DS) of the algorithm. If MPS differs from DS the output is 'Bugs present'; if MPS matches DS while bias or entropy is off, the output is 'No bugs, noise present.' The paper validates this on Grover, Deutsch-Jozsa, and Simon's algorithms with simulated noise and thousands of random circuits, and supplies a formula for the threshold noise level above which the diagnostic stops working.

What carries the argument

The central object is the Most Probable States set $\mathrm{MPS}$: the outcome eigenstates whose measured probability lies within $r = 5\%$ of the highest-probability state. It is compared with Desired States ($\mathrm{DS}$), the $\mathrm{MPS}$ of a bug-free, noise-free run, i.e. the measurement outcomes that give the correct answer. Two scalar companions are bias ($\beta$, total probability mass outside $\mathrm{DS}$, expected near zero in a clean run) and entropy ($S$, expected near $\log_2 |\mathrm{DS}|$ in a clean run). The bridge between them is Threshold Noise Level($C$), estimated in the average case as $$P^* = \left(1 - \frac{|\mathrm{DS}|}{2^n}\right) \frac{1}{|G|},$$ where $n$ is the number of measured qubits and $|G|$ is the gate count. Noise below this threshold leaves $\mathrm{MPS}$ unchanged; noise at or above it makes every state roughly equally likely, so the diagnostic declares 'Noise too high.' Algorithm 1 is the decision procedure that maps $(\beta, S, \mathrm{MPS}, \mathrm{DS})$ to the four output-dilemma cases.

What would settle it

Run a buggy Grover circuit in which the oracle phase is wrong by a small angle, so the marked state remains the most probable outcome but with lower probability than in the correct version; with depolarizing noise held below the paper's threshold and 10,000 shots, if $\mathrm{MPS} = \mathrm{DS}$ in the output histogram, then Algorithm 1 would classify the bug as 'No bugs, noise present' and the claim that all bugs change MPS is refuted.

Watch

Extended reading notes

Core claim

The discovery is that, in the regime the paper calls sub-threshold noise, the Most Probable States of a correctly implemented quantum circuit are invariant under hardware noise, but not under bugs. Since a meaningful quantum algorithm concentrates probability on its solution states, the desired states are known in advance; noise below Threshold Noise Level($C$) takes mass away from those states and spreads it over many others, yet the set of states within 5% of the top probability remains $DS$. A bug, by contrast, re-weights the distribution so that states outside $DS$ become the most probable, giving $\mathrm{MPS} \neq \mathrm{DS}$. This invariant is the load-bearing observation behind Algorithm 1: check whether $\mathrm{MPS} = \mathrm{DS}$, then use bias and entropy to separate 'clean' from 'noisy'; if $\mathrm{MPS} \neq \mathrm{DS}$ under sub-threshold noise, declare a bug. The claim is empirical, established on Grover, Deutsch-Jozsa, and Simon's algorithms, plus mutation experiments on random circuits, rather than proven from first principles.

Load-bearing premise

The method assumes that every software bug changes which output states are most probable; a bug that only slightly lowers the probability of the correct answers, or that disturbs only qubits that are never measured, would leave $\mathrm{MPS} = \mathrm{DS}$ and be reported as 'No bugs, noise present.'

Editorial extensions

If this is right

  • A developer can classify a bad run without error mitigation or machine learning: measure the output histogram, compare $\mathrm{MPS}$ to $\mathrm{DS}$, and read off the diagnosis.
  • The threshold formula gives a pre-run sanity check: if the estimated hardware noise level exceeds $P^*$, the run is too noisy to interpret and should not be used for debugging.
  • For algorithms with known desired states, a mismatch $\mathrm{MPS} \neq \mathrm{DS}$ becomes actionable evidence of a code bug even when the hardware is demonstrably noisy.
  • The entropy check distinguishes a perfectly clean run from a merely acceptable noisy one, so the method also catches silent degradation of results.
  • The same statistical metrics extend, in principle, to any quantum algorithm whose theoretical set of desired states is known.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not develop this, but if $\mathrm{MPS}$-shift is stable under noise and not under bugs, it could serve as a mutation-testing oracle, letting tools automatically label mutants as 'output-changing' versus 'output-preserving.'
  • The threshold formula is derived for independent, depolarizing-like noise; on real hardware with correlated errors or crosstalk, the numerical value of $P^*$ would likely need per-device recalibration rather than direct reuse.
  • The method presupposes knowledge of $\mathrm{DS}$, so an automated way to infer desired states from a program's specification would be the natural next step toward covering probabilistic algorithms such as VQE or QAOA.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper proposes a statistical approach, called the Bias-Entropy Model, to distinguish quantum software bugs from hardware noise in NISQ programs. It defines Most Probable States MPS(r), Desired States DS, bias beta, and entropy S, and presents Algorithm 1 that returns one of four diagnostics depending on whether beta is near zero, whether S approximates log2(|DS|), and whether MPS equals DS. The paper also derives a threshold noise level P* = (1 - |DS|/2^n)/|G| and validates the approach on Grover's, Deutsch-Jozsa, and Simon's algorithms using Qiskit simulators, depolarizing noise models, and Muskit-generated mutants. The experimental results for selected mutations show that these bugs shift MPS while sub-threshold noise does not, but the paper provides no formal proof that all bugs shift MPS.

Significance. If the central claim were established, the method would offer a cheap, practical diagnostic for NISQ quantum programs, and the paper deserves credit for making its code open-source and for testing on three canonical algorithms. The paper also wisely restricts its claims to algorithms whose DS is known in advance. However, the significance is conditional: the method's bug-detection branch rests on an unproven sensitivity assumption, the threshold derivation is heuristic, and the paper does not address finite-shot statistical variability. These gaps limit the reliability of the claimed 'effective and practical applicability' until addressed.

major comments (4)
  1. [Section III-B, Algorithm 1] The claim that 'Bugs will cause the MPS of the probability distribution to change' is asserted without proof and is not true for all bugs. For example, a mutation that changes a balanced Deutsch-Jozsa oracle to a different balanced function leaves the measured output distribution (all nonzero states) unchanged, so MPS=DS even though the implementation is not the one intended. Likewise, a bug that perturbs probabilities by less than the r% window used to define MPS(5) will not change the most probable set. Because the else branch of Algorithm 1 returns 'Bugs present' only when MPS != DS, such bugs are misclassified as 'No bugs, Noise present'. The paper's experiments (Table I, Figs. 7, 10, 13) cover only selected mutations that do shift MPS, and the random-circuit study in Section IV-B only reports entropy distributions, not MPS coverage. Please either prove the sensitivity guarantee for a precisely defined class of bugs, or restrict the method's claims to a class accompanied by an empirical coverage analysis.
  2. [Section III-C, average case analysis] The formula P* = (1 - |DS|/2^n) / |G| is derived by equating the union-bound upper bound |G|P to the bias of a uniform distribution, but the threshold is defined as the least noise level at which MPS departs from DS for a correct circuit. An upper bound on the probability of at least one gate error does not imply that MPS changes at that noise level, so the derivation does not actually estimate the threshold it purports to estimate. Moreover, Assumption 1 ('a gate affected by noise will always lead to an anomalous outcome' and 'noise effects on multiple gates will not cancel') is unproven; two depolarizing errors can compose to the identity, and measurement can mask errors on unmeasured qubits. Please either replace this with a rigorous bound tied directly to the MPS condition, or explicitly characterize P* as an empirical heuristic and justify it with additional sensitivity experiments.
  3. [Algorithm 1; Section II-D] The paper calls the approach statistical, but Algorithm 1 uses point estimates of beta, S, and MPS without any confidence intervals or hypothesis tests. With a finite number of shots (10,000), the empirical MPS is itself a random set: states with probabilities within the sampling uncertainty of each other can swap order, so MPS=DS may hold for one run and fail for another. This is particularly relevant for algorithms where the desired states have unequal probabilities (as in Grover's algorithm, where marked states are not exactly equally likely). The authors should either provide a statistical test for the comparisons beta≈0, S≈log2(|DS|), and MPS=DS, or justify that the chosen number of shots is sufficient to make misclassification probability negligible.
  4. [Section V-A, balanced Deutsch-Jozsa] With |G| = 144.5 and |DS| = 7, the computed threshold is P* = 0.00087, meaning that any uniform gate error probability above about 0.087% causes Algorithm 1 to return 'Noise too high' for a 3-qubit balanced Deutsch-Jozsa circuit. This is well below typical current device gate-error rates and would make the method inapplicable to circuits of this size on real hardware. The experimental entropy curve in Fig. 11 appears to saturate at a much higher noise level, so the theoretical estimate and the empirical observation are not reconciled. Please discuss this discrepancy and its practical consequences, or adjust the threshold definition so that it corresponds to the MPS-change point rather than to a uniform-distribution calibration.
minor comments (4)
  1. [Throughout] The notation 'M P S' is cumbersome; use 'MPS' consistently. Also, 'S ≈ log |DS|' should be written 'S ≈ log2(|DS|)' with the base explicit.
  2. [Algorithm 1] The indentation in Algorithm 1 makes the control flow ambiguous: the final 'else' appears to pair with the outer 'if', but the intermediate 'else if' is placed inside the outer then-branch. Please restructure the pseudocode with clear begin/end markers.
  3. [Section IV-D, Table I] The caption says 'given that the noise level is fixed' but does not state the value of the fixed noise level; please report it.
  4. [Section III-C] The 'pessimistic estimate' P~* = 1/((|DS|+1)|G|) is introduced but then never used or referenced again; either remove it or explain its role relative to the average-case P*.

Circularity Check

1 steps flagged · score 4.0 of 10

The 'No bugs, Noise present' branch is self-definitional via Threshold Noise Level(C); the 'Bugs present' branch relies on an unproven converse that bugs always change MPS, though it retains independent empirical grounding.

  1. self definitional [Section III-B (Definition 3) and Algorithm 1]
    "Definition 3 Threshold Noise Level ( C): The least noise level at which MPS != DS when a correct implementation of the quantum circuit C is run on a noisy quantum computer. ... else if MPS = DS then return “No bugs, Noise Present”; end else return “Bugs present”"

    By Definition 3, Threshold Noise Level(C) is the noise level at which MPS first departs from DS for a correct implementation. Hence, for every noise level below that threshold, a correct circuit has MPS = DS by construction. Algorithm 1's 'No bugs, Noise present' branch returns exactly this definitional guarantee, so that branch is not an independently derived empirical finding. The complementary 'Bugs present' branch requires the converse statement that every bug changes MPS, which is asserted in Section III-A ('bugs will cause the MPS of the probability distribution to change') rather than proven. Section VI concedes that algorithmic bugs remain underrepresented in the experiments.

full rationale

The paper contains one genuine but localized circular step. The threshold noise level is defined as the point where MPS first becomes unequal to DS for a correct circuit, so the 'No bugs, Noise present' classification for sub-threshold noise is true by definition. That branch therefore carries no evidential weight beyond the definition. The central 'Bugs present' branch is not itself circular: it depends on the substantive claim that bugs always shift MPS away from DS, which the authors support with selected Muskit mutations and case studies involving extra Pauli gates before measurement. However, the Threats to Validity section explicitly states that algorithmic bugs remain underrepresented and that findings may not generalize to all bug types, so the full inverse implication 'MPS != DS implies buggy' is an unproven generalization. Because the article provides independent empirical evaluation of particular mutants and the threshold estimate itself is compared with experiments, the overall derivation does not reduce entirely to its inputs; the circularity is partial and confined to the noise-only classification branch.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central claim rests on several unproved modeling assumptions: bugs always change the most probable states, noise errors never cancel, desired states are uniform, and noise is stationary. These are not derived from first principles, and the first is not covered by the experiments' mutation set.

free parameters (3)
  • r in MPS(r) = 5 (chosen, not fitted)
    MPS is defined as the set of states within r percent of the most probable state; r=5 is set without sensitivity analysis.
  • beta threshold for 'beta approx 0' = unspecified
    Algorithm 1 requires an approximate comparison but no numeric tolerance is given.
  • entropy tolerance for 'S approx log2(|DS|)' = unspecified
    Algorithm 1 requires an approximate equality between measured entropy and log2(|DS|) but no tolerance is defined.
assumptions (5)
  • domain assumption Noise level remains constant across shots.
    Stated in Section III-B; needed to compare probability mass functions across runs.
  • ad hoc to paper A gate affected by noise always produces an anomalous outcome, and noise effects on multiple gates never cancel.
    Section III-C assumption 1; used to derive the threshold via a union bound. It is conservative and not generally true.
  • domain assumption In the absence of noise, each state in DS occurs with probability 1/|DS|.
    Section III-C assumption 3; used to compute the threshold. It is exact only for uniform desired distributions such as Simon's algorithm, and is approximate for Grover and for the balanced Deutsch-Jozsa case.
  • domain assumption Every bug alters MPS so that MPS != DS.
    Section III-B; this is the load-bearing premise of the bug-detection branch. It is not proven and is not true for all possible programming errors.
  • standard math Boole's inequality: p(union of Ai) <= sum of p(Ai).
    Used in Section III-C to bound the probability that at least one gate is affected by noise.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Distinguishing Quantum Software Bugs from Hardware Noise: A Statistical Approach." pith.science (2026). https://pith.science/paper/KNCKMCYF

@misc{pith2026250720475,
  author       = {Pith},
  title        = {Pith review of: Distinguishing Quantum Software Bugs from Hardware Noise: A Statistical Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KNCKMCYF}},
  note         = {Machine review of arXiv:2507.20475}
}
read the original abstract

Quantum computing in the Noisy Intermediate-Scale Quantum (NISQ) era presents significant challenges in differentiating quantum software bugs from hardware noise. Traditional debugging techniques from classical software engineering cannot directly resolve this issue due to the inherently stochastic nature of quantum computation mixed with noises from NISQ computers. To address this gap, we propose a statistical approach leveraging probabilistic metrics to differentiate between quantum software bugs and hardware noise. We evaluate our methodology empirically using well-known quantum algorithms, including Grover's algorithm, Deutsch-Jozsa algorithm, and Simon's algorithm. Experimental results demonstrate the efficacy and practical applicability of our approach, providing quantum software developers with a reliable analytical tool to identify and classify unexpected behavior in quantum programs.

Figures

Figures reproduced from arXiv: 2507.20475 by the authors.

Figure 1
Figure 1. Comparison of Grover’s algorithm under different [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Outcome of a correct implementation of Grover’s algorithm under different noise levels [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Effect of varying noise levels on a correct implemen [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: Noise Level vs Bias graph for Grover’s algorithm [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Results for bug-free DJA with Constant functions [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Results for buggy DJA with Constant functions [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Entropy vs Noise-level for DJA-Constant • n = 3 • |DS| = 1 • |G| = 8.5 (averaged over 10000 constant functions) Applying the formula for the theoretical bound, we get P ∗ = 0.103. Checking the value of entropy for this bound in [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Results for bug-free DJA with Balanced functions [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Results for buggy DJA with Balanced functions [PITH_FULL_IMAGE:figures/full_fig_p010_10.png]
Figure 11
Figure 11. Figure 11: Entropy vs Noise-level for DJA-Balanced backend at various different noise levels. From Fig. 12a, we measure β = 0 and the entropy, S = 1.999 ≈ log2|DS|. Thus, the Algorithm 1 would rightly return “No bugs, No noise”. Fig. 12b shows the result when Simon’s algorithm i…
Figure 12
Figure 12. Figure 12: Results for bug-free implementation of Simon’s Algorithm at various noise levels [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: Results for a buggy implementation of Simon’s Algorithm [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 14
Figure 14. Figure 14: Entropy vs Noise curve for Simon’s algorithm [PITH_FULL_IMAGE:figures/full_fig_p011_14.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

35 extracted references · 25 canonical work pages

  1. [1]

    Qiskit documentation

    Qiskit Development Team. Qiskit documentation. [Online]. Available: https://github.com/Qiskit/documentation

  2. [2]

    Azure quantum documentation

    Microsoft Corporation. Azure quantum documentation. [Online]. Available: https://learn.microsoft.com/en-us/azure/quantum/

  3. [3]

    Pennylane documentation

    Xanadu. Pennylane documentation. [Online]. Available: https://docs.p ennylane.ai/en/stable/

  4. [4]

    Noisy intermediate-scale quantum algorithms,

    K. Bharti, A. Cervera-Lierta, T. H. Kyaw, T. Haug, S. Alperin-Lea, A. Anand, M. Degroote, H. Heimonen, J. S. Kottmann, T. Menke et al., “Noisy intermediate-scale quantum algorithms,” Reviews of Modern Physics, vol. 94, no. 1, p. 015004, 2022

  5. [5]

    Understanding the impact of quantum noise on quantum programs,

    Z. Pan, Y . Feng, Z. Li, Y . Liu, and Y . Li, “Understanding the impact of quantum noise on quantum programs,” in 2023 IEEE International Con- ference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 2023, pp. 426–437

  6. [6]

    Benchmarking quantum computers and the impact of quantum noise,

    S. Resch and U. R. Karpuzcu, “Benchmarking quantum computers and the impact of quantum noise,” ACM Comput. Surv., vol. 54, no. 7, Jul

  7. [7]

    Mitigating Noise in Quantum Software Testing Using Machine Learning

    A. Muqeet, T. Yue, S. Ali, and P. Arcaini, “Mitigating noise in quantum software testing using machine learning,” 2024. [Online]. Available: https://arxiv.org/abs/2306.16992

  8. [8]

    A fast quantum mechanical algorithm for database search,

    L. K. Grover, “A fast quantum mechanical algorithm for database search,” in Proceedings of the twenty-eighth annual ACM symposium on Theory of computing , 1996, pp. 212–219

Show all 35 references
  1. [9]

    Rapid solution of problems by quantum computation,

    D. Deutsch and R. Jozsa, “Rapid solution of problems by quantum computation,” Proceedings of the Royal Society of London. Series A: Mathematical and Physical Sciences , vol. 439, no. 1907, pp. 553–558, 1992

  2. [10]

    On the power of quantum cryptography,

    D. R. Simon, “On the power of quantum cryptography,” in 35th Annual Symposium on Foundations of Computer Science, Santa Fe, New Mexico, USA. sn, 1994, pp. 116–123

  3. [11]

    Muskit: A mutation analysis tool for quantum software testing,

    E. Mendiluze, S. Ali, P. Arcaini, and T. Yue, “Muskit: A mutation analysis tool for quantum software testing,” pp. 1266–1270, 2021

  4. [12]

    M. A. Nielsen and I. L. Chuang, Quantum Computation and Quantum Information. Cambridge University Press, 2010

  5. [13]

    Bugs in quantum computing platforms: an empirical study,

    M. Paltenghi and M. Pradel, “Bugs in quantum computing platforms: an empirical study,” Proceedings of the ACM on Programming Languages , vol. 6, no. OOPSLA1, p. 1–27, Apr. 2022. [Online]. Available: http://dx.doi.org/10.1145/3527330

  6. [14]

    Efficient learning of the structure and parameters of local pauli noise channels,

    C. Rouz ´e and D. S. Franc ¸a, “Efficient learning of the structure and parameters of local pauli noise channels,” 2023. [Online]. Available: https://arxiv.org/abs/2307.02959

  7. [15]

    Scaling up to problem sizes: An environmental life cycle assessment of quantum computing,

    S. Cordier, K. Thibault, M.-L. Arpin, and B. Amor, “Scaling up to problem sizes: An environmental life cycle assessment of quantum computing,” 2025. [Online]. Available: https://arxiv.org/abs/2411.00118

  8. [16]

    Qiskit Aer: High performance simulators for quantum circuits,

    Qiskit, “Qiskit Aer: High performance simulators for quantum circuits,” https://github.com/Qiskit/qiskit-aer

  9. [17]

    Quantum software engineering: Landscapes and horizons,

    J. Zhao, “Quantum software engineering: Landscapes and horizons,” arXiv preprint arXiv:2007.07047 , 2020

  10. [18]

    Quantum software engineering: Roadmap and challenges ahead,

    J. M. Murillo, J. Garcia-Alonso, E. Moguel, J. Barzen, F. Leymann, S. Ali, T. Yue, P. Arcaini, R. P ´erez-Castillo, I. Garc ´ıa Rodr ´ıguez de Guzm´an, M. Piattini, A. Ruiz-Cort ´es, A. Brogi, J. Zhao, A. Miranskyy, and M. Wimmer, “Quantum software engineering: Roadmap and cha...

  11. [19]

    Statistical assertions for validating patterns and finding bugs in quantum programs,

    Y . Huang and M. Martonosi, “Statistical assertions for validating patterns and finding bugs in quantum programs,” in Proceedings of the 46th International Symposium on Computer Architecture, 2019, pp. 541–553

  12. [20]

    Quantum service-oriented computing: current landscape and challenges,

    E. Moguel, J. Rojo, D. Valencia, J. Berrocal, J. Garcia-Alonso, and J. M. Murillo, “Quantum service-oriented computing: current landscape and challenges,” Software Quality Journal , vol. 30, no. 4, pp. 983–1002, 2022

  13. [21]

    Quanfuzz: Fuzz testing of quantum program,

    J. Wang, M. Gao, Y . Jiang, J. Lou, Y . Gao, D. Zhang, and J. Sun, “Quanfuzz: Fuzz testing of quantum program,” 2018. [Online]. Available: https://arxiv.org/abs/1810.10310

  14. [22]

    Qmutpy: a mutation testing tool for quantum algorithms and applications in qiskit,

    D. Fortunato, J. Campos, and R. Abreu, “Qmutpy: a mutation testing tool for quantum algorithms and applications in qiskit,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , ser. ISSTA 2022. New York, NY , USA: Association for Co...

  15. [23]

    A preliminary study on generating well-formed q# quantum programs for fuzz testing,

    M. Trinca, J. F. Ferreira, and R. Abreu, “A preliminary study on generating well-formed q# quantum programs for fuzz testing,” in 2022 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2022, pp. 118–121

  16. [24]

    Poster: Fuzz testing of quantum program,

    J. Wang, F. Ma, and Y . Jiang, “Poster: Fuzz testing of quantum program,” in 2021 14th IEEE Conference on Software Testing, Verification and Validation (ICST), 2021, pp. 466–469

  17. [25]

    Mutation testing of quantum programs: A case study with qiskit,

    D. Fortunato, J. CAMPOS, and R. ABREU, “Mutation testing of quantum programs: A case study with qiskit,” IEEE Transactions on Quantum Engineering, vol. 3, pp. 1–17, 2022

  18. [26]

    Quantum Computing in the NISQ era and beyond,

    J. Preskill, “Quantum Computing in the NISQ era and beyond,” Quantum, vol. 2, p. 79, Aug. 2018. [Online]. Available: https: //doi.org/10.22331/q-2018-08-06-79

  19. [27]

    Testing and debugging quantum programs: The road to 2030,

    N. C. L. Ramalho, H. A. de Souza, and M. L. Chaim, “Testing and debugging quantum programs: The road to 2030,” 2024. [Online]. Available: https://arxiv.org/abs/2405.09178

  20. [28]

    A modified depolarization approach for efficient quantum machine learning,

    B. Khanal and P. Rivas, “A modified depolarization approach for efficient quantum machine learning,” Mathematics, vol. 12, no. 9, 2024. [Online]. Available: https://www.mdpi.com/2227-7390/12/9/1385

  21. [29]

    Quantum and private capacities of low-noise channels,

    F. Leditzky, D. Leung, and G. Smith, “Quantum and private capacities of low-noise channels,” Physical Review Letters , vol. 120, no. 16, Apr

  22. [30]

    Qiskit aer: Device noise simulation

    Q. D. Team, “Qiskit aer: Device noise simulation.” [Online]. Available: \url{https://qiskit.github.io/qiskit-aer/tutorials/2 \ device\ noise\ sim ulation.html}

  23. [31]

    Qiskit IBM Runtime Fake Provider

    IBM Quantum, “Qiskit IBM Runtime Fake Provider.” [Online]. Available: https://docs.quantum.ibm.com/api/qiskit-ibm-runtime/fake-p rovider

  24. [32]

    Qiskit Random Circuit Generator

    ——, “Qiskit Random Circuit Generator.” [Online]. Available: https://docs.quantum.ibm.com/api/qiskit/0.37/qiskit.circuit.random.ran dom\ circuit

  25. [33]

    Current numbers of qubits and their uses,

    T. Ichikawa, H. Hakoshima, K. Inui, K. Ito, R. Matsuda, K. Mitarai, K. Miyamoto, W. Mizukami, K. Mizuta, T. Mori, Y . Nakano, A. Nakayama, K. N. Okada, T. Sugimoto, S. Takahira, N. Takemori, S. Tsukano, H. Ueda, R. Watanabe, Y . Yoshida, and K. Fujii, “Current numbers of qubit...

  26. [2018]

    Available: http://dx.doi.org/10.1103/PhysRevLett.120.1 60503

    [Online]. Available: http://dx.doi.org/10.1103/PhysRevLett.120.1 60503

  27. [2021]

    Available: https://doi.org/10.1145/3464420

    [Online]. Available: https://doi.org/10.1145/3464420

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.