Pith. sign in

REVIEW 3 major objections 4 minor 31 references

For static variational circuits, compile-once tensor-native execution cuts training time by a median of about 27x on GPUs, the paper argues.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-02 06:51 UTC pith:6CJBACHL

load-bearing objection Solid, carefully measured empirical study of when compile-once PyTorch statevector simulation wins; headline speedups are plausible in their setup, but the two FD-matched numbers need reconciliation and the baselines need a compile-once fairness check. the 3 major comments →

arxiv 2607.11985 v2 pith:6CJBACHL submitted 2026-07-13 quant-ph cs.ETcs.LG

VQCSim: When Does Compile-Once Statevector Simulation Beat Generic Quantum Frameworks?

Anton Firc , Martin Pere\v{s}\'ini , Vojt\v{e}ch Mr\'azek , Kamil Malinka , Vojt\v{e}ch Stan\v{e}k , Zbyn\v{e}k Li\v{c}ka , Nouhaila Innan , Walid El Maouaki
show 2 more authors
Alberto Marchisio Muhammad Shafique
This is my paper
classification quant-ph cs.ETcs.LG
keywords quantum machine learningstatevector simulationcompile-once loweringvariational quantum circuitsautomatic differentiationGPU memory tradeoffbackend selectionhybrid quantum-classical computing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper claims that for small, fixed-structure variational circuits used in hybrid quantum machine learning, most of the runtime in generic simulation goes to framework dispatch and orchestration, not to the underlying statevector arithmetic. It proposes VQCSim, a compile-once path that lowers a static circuit once into a cached sequence of batched tensor operations with automatic differentiation; every later evaluation skips re-construction and re-dispatch. Across five GPUs, pooled median speedups are measured at 4.5x for inference and 26.8x for training over generic frameworks, and 3.3x remains when every backend is forced onto the same finite-difference gradient rule. These gains are bought with significantly higher GPU memory, and they concentrate in moderate-to-large batch regimes; at batch size one the picture is mixed. The paper's answer to 'when is compile-once worth it' is: for static circuits, under memory feasibility, whenever workloads aggregate.

Core claim

The central claim is that compile-once specialization changes which resource becomes the practical limit. Generic quantum frameworks scale badly with batch size because each forward pass pays circuit reconstruction, host dispatch, and gradient-stack overhead; they are runtime-limited. VQCSim compiles the circuit once into a cached execution path, then applies batched gate kernels and native automatic differentiation, so wall time stays low but peak VRAM grows with the state and with retained backward intermediates; it is memory-limited. The evidence is threefold: an end-to-end validation of 87.7% on 463 static benchmark circuits, a full ablation in which disabling native automatic differenti

What carries the argument

The load-bearing mechanism is a compile-once execution path for static circuits—circuits whose gate sequence and wiring are fixed at compile time, with only rotation angles varying. A normalized circuit description is parsed once into a gate list; constant gates become cached unitary matrices, parametrized gates stay symbolic, and each forward pass applies the sequence to a batched state tensor via permutation, reshape, and batched tensor-matrix multiplication. Because the whole path stays inside a tensor-autodiff framework, gradients with respect to parameters come from native automatic differentiation rather than repeated circuit evaluation. This removes per-call framework dispatch and rep

Load-bearing premise

The headline speedups assume the timed generic frameworks, run through a unified harness with fixed transpilation and a finite-difference policy, represent how users actually run these workloads; if practitioners normally use precompiled backends or adjoint-style native differentiation, the measured gap could be smaller.

What would settle it

Run the same parity-checked static circuits on the same five GPUs with a generic backend that already offers tensor-native execution, native automatic differentiation, and a cached/precompiled circuit, using the same warmup-and-repeat protocol; if its median training time approaches VQCSim's, the claimed compile-once advantage is not specific to this design.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Static variational circuits—the ansätze used in QAOA, VQE, and quantum-neural-network layers—can all be lowered into the cached path; all 463 tested static circuits lowered successfully, with 87.7% passing end-to-end semantic validation.
  • The speedup is a batch effect: inference at batch 1 is mixed, but from batch 8 upward, and in essentially all training regimes, VQCSim is the faster backend on every tested GPU.
  • Native automatic differentiation, not the execution path alone, is the main source of the training speedup; a matched-finite-difference comparison still leaves a significant 2.15x simulator-level advantage.
  • The throughput gain comes with a memory cost: native-training peak VRAM can reach tens of gigabytes where generic frameworks stay below half a gigabyte, so memory feasibility is a required pre-filter.
  • The empirical regime map transfers across GPU models; a selector trained on one device keeps 91–98% oracle agreement on four other devices.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the compile-once idea transfers to other tensor backends or to noisy simulation with fixed noise models, the same caching benefit could appear there; the paper only evaluates ideal statevector simulation.
  • Because the speedup shrinks as qubit count grows, the largest practical payoff is likely in design-space exploration loops that sweep many small circuits; the paper's own selector is one such use, but a search loop that reuses a compiled pool of candidate circuits would compound the amortization.
  • A natural stress test would be to vary parameter count while holding gate count fixed: the autograd advantage should shrink as parameter-dependent gates become a smaller fraction of the work, which is a falsifiable prediction the paper does not report.
  • The memory bottleneck suggests concrete extensions—gradient checkpointing, reversible gate sequences, or streaming of backward intermediates—that could push the feasibility boundary by one to two qubits, but none are implemented or tested.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper introduces VQCSim, a compile-once, PyTorch-native statevector execution path for static variational quantum circuits, and evaluates it as a CAD-style decision aid for hybrid QML workflows. The central empirical claims are: (i) VQCSim lowers all 463 static MQT Bench circuits and passes external parity checks for 87.7% (91.6% among completed checks); (ii) on a five-GPU common subset it achieves pooled median speedups of 4.49x for native inference and 26.78x for native training, with a 3.31x advantage under matched finite-difference (FD) training; (iii) an ablation attributes the largest gain to native autograd (27.6x), with compile-once caching and batch vectorization as secondary contributors; and (iv) a trained backend selector, vqcsim-oracle, transfers across GPUs with 91.1--97.7% top-1 agreement. The paper frames the contribution as determining 'when compile-once specialization is the right choice' for static circuits, and releases all code and artifacts.

Significance. If the empirical claims hold, the paper makes a useful and actionable contribution: it provides a systematic applicability study, a mechanism-level decomposition, and a validated backend-selection rule that the QML community can use to decide when a compile-once, Torch-native simulator is preferable to general-purpose frameworks. The methodology is a clear strength: semantic parity checks before timing, explicit failure accounting, warm-up/repeat protocols, paired Wilcoxon tests, cross-GPU evaluation, and a held-out family-size split for the selector are all reported carefully. The paper also ships code and reproducibility manifests, which supports verification. The central risk is whether the baseline configurations are representative of generic QML practice; if the generic frameworks are unfairly disadvantaged by re-transpiling on every iteration, the headline speedups, particularly the FD-matched advantage, would shrink when measured against a properly precompiled generic baseline.

major comments (3)
  1. [§4.2.2–4.2.3, Tables 2 and 4] The FD-matched training speedup is reported inconsistently across the two key tables without reconciliation. Table 2 lists a pooled median of 3.31x on the 'strict common cross-GPU subset', while §5.3/Table 4 reports 2.15x on n=446 for the same FD-matched policy. The paper never explains which scope is the headline claim or why the numbers differ. Moreover, Table 4 shows that the Qiskit FD-matched median is only 1.036x (r=0.299), i.e. near parity, so the pooled 'clear simulator-level advantage' is driven mainly by PennyLane and TensorCircuit. This scope-sensitivity and framework-dependence should be stated explicitly in the abstract and conclusions, or the discrepancy should be resolved with a single consistent reporting choice.
  2. [§4.2.3, timing methodology] The unified harness states that PennyLane QNodes are instantiated once and reused across timing repeats, but it does not state whether Qiskit circuits are transpiled once before the timed region or whether backend.run re-transpiles the circuit on every call. If the latter occurs, the timed baselines include repeated Qiskit compilation overhead, which is precisely the overhead that VQCSim's compile-once cache eliminates. The internal 'no compile-once' ablation in Table 5 removes only VQCSim's caching and does not control for the baselines' ability to cache. This is load-bearing for the FD-matched advantage (the number intended to isolate execution path from autograd), because an optimized, once-transpiled generic baseline could erode that advantage. The authors should either document that Qiskit circuits are compiled once before timing (e.g., by passing a pre-transpiled Qiskit circuit to
  3. [§5.2, Figure 5 and memory tradeoff] The paper's central interpretation, that VQCSim trades memory for throughput, is supported by the VRAM numbers but the comparison is only among 'successful runs'. The paper reports VQCSim native-training VRAM of 15.0--48.1GB versus 0.26--0.49GB for baselines, and states that many generic-framework failures are timeouts rather than OOM. However, the paper does not quantify how many RQ2 workloads are excluded from the speedup tables due to VQCSim OOM while the baselines succeed. If VQCSim's OOM rate is substantial in the tested qubit/batch grid, the median speedup is computed on a truncated sample and the regime map in Figure 6 would overstate coverage. The paper should report success/failure counts broken down by backend and workload, especially near the high-end boundary.
minor comments (4)
  1. [Abstract and §1] Typographical: 'whencompile-once' is missing a space in the abstract; the same phrase appears in the introduction. Also 'TQml' is inconsistently capitalized when referring to the TQml Simulator.
  2. [Figure 2] The figure refers to 'GenericFastQasmCircuit' but this class is not defined in the text. Please add a one-sentence description or rename it to match the main-text terminology.
  3. [§4.2.3] The text says 'In the strict RQ2 sweep, training uses a matched central finite-difference policy' but Table 2 reports both native and FD-matched training. Clarify that Table 2's native-training rows come from separate auxiliary runs, not from the strict sweep, to avoid the impression that all results share the same protocol.
  4. [§5.4, Figure 6] The regime map appears coarse (e.g., only labels for a few qubit/batch cells) and its derivation from the underlying RQ2 data is not fully described. Please specify the exact decision rule that draws the green/mixed/OOM boundaries and indicate the number of data points per cell.

Circularity Check

0 steps flagged

No significant circularity: speedups are direct runtime measurements with explicit protocols, and the only fitted component is evaluated on held-out data.

full rationale

The paper's central claims are empirical runtime ratios, not derived quantities. Tables 1-4 report measured baseline runtime divided by VQCSim runtime under the protocol in §4.2.2-4.2.3, with parity checking before timing and a matched finite-difference control in §4.2.4 that isolates the differentiation-policy component. No fitted parameter is embedded in the speedup numbers. The only learned component, vqcsim-oracle, is trained on RQ2 runtime/memory records and evaluated on a held-out family-size split plus cross-GPU transfer (§4.2.5), so its accuracy is not self-confirming. Self-citations such as [17], [18], [21], and [28] appear in related-work or acknowledgment contexts and are not load-bearing for the measured speedup claims. The manuscript explicitly discloses its scope (ideal statevector simulation, static circuits, GPU memory tradeoff, validation limits), and the skeptic's concern about generic-framework baseline configurability is a benchmarking-fairness issue, not a circularity of derivation. No step reduces, by construction or by self-citation, to the inputs of the claimed result.

Axiom & Free-Parameter Ledger

2 free parameters · 3 axioms · 0 invented entities

This is an empirical systems benchmark rather than a mathematical derivation, so there are no physical axioms. The listed items are the load-bearing modeling assumptions: exact-statevector scope, MQT Bench representativeness, and fairness of the transpilation/differentiation policies. The only fitted component is the backend-selector model, whose parameters are not disclosed.

free parameters (2)
  • vqcsim-oracle model weights/hyperparameters = not reported
    The backend selector is trained on RQ2 runtime/memory records; architecture, hyperparameters, learned coefficients, and feature importance are not specified in the paper, so the 91.1-97.7% transfer accuracies cannot be independently inspected.
  • regime-map decision thresholds (batch-1 guard, memory-feasibility overhead term) = qualitative/hand-set from benchmark data
    Section 5.4 describes a built-in low-batch inference guard and a memory overhead term predicted from structural descriptors; these thresholds are chosen from observed crossover behavior and are not derived from first principles.
axioms (3)
  • domain assumption Ideal statevector simulation is the correct reference model for the targeted QML workloads.
    The entire comparison is exact noiseless statevector simulation; noise, sampling, and hardware effects are out of scope (§1, §6).
  • domain assumption MQT Bench ALG-level static circuits up to size 20 are representative of current QML variational workloads.
    Generalizing the speedups and selector to wider QML practice assumes this benchmark population represents the workloads practitioners care about (§4.2.1).
  • domain assumption The fixed Qiskit transpilation policy (basis gate set, optimization_level=0, fixed seed) preserves semantics and does not bias performance.
    Used for both VQCSim and baselines and checked by parity, but no comparison to alternative transpilation choices is provided (§4.2.2).

pith-pipeline@v1.3.0-alltime-deepseek · 14104 in / 16889 out tokens · 165194 ms · 2026-08-02T06:51:04.522191+00:00 · methodology

0 comments
read the original abstract

Hybrid quantum-classical machine learning workflows repeatedly evaluate many small parametrized circuits during training and model exploration. In this regime, framework dispatch and orchestration overhead often dominate runtime. Prior simulators accelerate execution but leave open the question of when compile-once specialization is the right choice for static variational circuits. We answer this question with VQCSim, a compile-once, PyTorch-native statevector execution path with native autograd. In a systematic MQT Bench study, VQCSim compiles all tested static circuits and provides 87.7% end-to-end semantic validation. Across a five-GPU evaluation set, VQCSim delivers pooled median speedups of 4.49x for native inference and 26.78x for native training, while retaining a 3.31x advantage under matched finite-difference training. Ablation identifies native autograd as the dominant source of acceleration (27.6x), with compile-once caching and batch vectorization contributing additional gains. The speedup trades higher GPU memory (VQCSim is memory-limited at the high end) for lower runtime. We derive a hardware-aware regime map and release vqcsim-oracle, an open-source backend selector with 91.1%-97.7% top-1 agreement (including cross-GPU transfers), enabling automatic simulator selection in QML design loops.

Figures

Figures reproduced from arXiv: 2607.11985 by Alberto Marchisio, Anton Firc, Kamil Malinka, Martin Pere\v{s}\'ini, Muhammad Shafique, Nouhaila Innan, Vojt\v{e}ch Mr\'azek, Vojt\v{e}ch Stan\v{e}k, Walid El Maouaki, Zbyn\v{e}k Li\v{c}ka.

Figure 1
Figure 1. Figure 1: Execution-path comparison for the VQC block in a hybrid quantum [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Generic baselines incur framework/runtime orchestration and re [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Median inference wall time versus qubit count for representative [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Cross-GPU generalization of VQCSim speedups. Rows are baseline– [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Pareto view of execution time versus peak GPU VRAM for VQCSim [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Hardware-aware regime map (RTX 5080, 16 GB). Rows correspond [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗

Review history (2 revisions) →

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 3 canonical work pages

  1. [1]

    Tabassum Ara, Ved Prakash Mishra, Manish Bali, and Anuradha Yenkikar

  2. [2]

    Ali Asadi et al. 2024. Hybrid Quantum Programming with PennyLane Lightning on HPC Platforms. arXiv:2403.02512

    Pith/arXiv arXiv 2024

  3. [3]

    Harun Bayraktar et al. 2023. cuQuantum SDK: A High-Performance Library for Accelerating Quantum Science. arXiv:2308.01999

    Pith/arXiv arXiv 2023

  4. [4]

    Ville Bergholm et al . 2018. PennyLane: Automatic Differentiation of Hybrid Quantum-Classical Computations. arXiv:1811.04968

    Pith/arXiv arXiv 2018

  5. [5]

    Yuxuan Du, Tao Huang, and Dacheng Tao. 2022. Quantum Circuit Architecture Search for Variational Quantum Algorithms.npj Quantum Information8, 1 (2022),

    2022

  6. [6]

    Siddhant Dutta, Nouhaila Innan, Sadok Ben Yahia, and Muhammad Shafique. 2025. QAS-QTNs: Curriculum reinforcement learning-driven quantum architecture search for quantum tensor networks. In2025 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 1. IEEE, 1739–1747

    2025

  7. [7]

    Franco, Felipe Mahlow, Pedro M

    Giovanni S. Franco, Felipe Mahlow, Pedro M. Prado, Guilherme E. L. Pexe, Lucas A. M. Rattighieri, and Felipe F. Fanchini. 2025. Quantum Phases Classifica- tion Using Quantum Machine Learning with SHAP-Driven Feature Selection. arXiv:2504.10673 [quant-ph] https://arxiv.org/abs/2504.10673

    Pith/arXiv arXiv 2025

  8. [8]

    Yaswitha Gujju, Atsushi Matsuo, and Rudy Raymond. 2024. Quantum machine learning on near-term quantum devices: Current state of supervised and unsu- pervised techniques for real-world applications.Phys. Rev. Appl.21 (Jun 2024), 067001. Issue 6. doi:10.1103/PhysRevApplied.21.067001

    work page doi:10.1103/physrevapplied.21.067001 2024

  9. [9]

    Ali Javadi-Abhari et al. 2024. Quantum Computing with Qiskit. arXiv:2405.08810. VQCSim: When Does Compile-Once Statevector Simulation Beat Generic Quantum Frameworks? ICCAD ’26, November 8–12, 2026, San Jose, CA, USA

    Pith/arXiv arXiv 2024

  10. [10]

    Shui Jiang et al. 2025. BQSim: GPU-Accelerated Batch Quantum Circuit Simula- tion Using Decision Diagram. InASPLOS. 79–94

    2025

  11. [11]

    Jones, Viki Kumar Prasad, Ulrich Fekl, and Hans-Arno Jacobsen

    Grier M. Jones, Viki Kumar Prasad, Ulrich Fekl, and Hans-Arno Jacobsen. 2026. Parametrized Quantum Circuit Learning for Quantum Chemical Applications. Journal of Chemical Information and Modeling(11 Mar 2026). doi:10.1021/acs. jcim.6c00376

    doi:10.1021/acs 2026

  12. [12]

    Amit Kharsa et al. 2024. Benchmarking Quantum Computer Simulation Software Packages: State Vector Simulators.arXiv preprint arXiv:2401.09076(2024)

    Pith/arXiv arXiv 2024

  13. [13]

    Michael Kölle, Alexander Feist, Jonas Stein, Sebastian Wölckert, and Claudia Linnhoff-Popien. 2025. Evaluating Parameter-Based Training Performance of Neural Networks and Variational Quantum Circuits. InComputational Science – ICCS 2025: 25th International Conference, Singapore, Singapore, July 7–9, 2025, Proceedings, Part IV(Singapore, Singapore). Spring...

    work page doi:10.1007/978-3-031-97635-3_33 2025

  14. [14]

    Poornima Kumaresan, Pavithra Muruganantham, Lakshmi Rajendran, and San- thosh Sivasubramani. 2026. GPU-Accelerated Quantum Simulation: Empirical Backend Selection, Gate Fusion, and Adaptive Precision. arXiv:2604.03816

    Pith/arXiv arXiv 2026

  15. [15]

    Viacheslav Kuzmin, Basil Kyriacou, Tatjana Protasevich, Mateusz Papierz, Mo Kordzanganeh, and Alexey Melnikov. 2026. TQml Simulator: optimized sim- ulation of quantum machine learning. arXiv:2506.04891 [quant-ph] https: //arxiv.org/abs/2506.04891

    arXiv 2026

  16. [16]

    Yuncheng Lu et al. 2025. Versatile Cross-Platform Compilation Toolchain for Schrödinger-Style Quantum Circuit Simulation. arXiv:2503.19894

    Pith/arXiv arXiv 2025

  17. [17]

    Alberto Marchisio, Andrea Massa, Vojtech Mrazek, Beatrice Bussolino, Maurizio Martina, and Muhammad Shafique. 2020. NASCaps: A Framework for Neu- ral Architecture Search to Optimize the Accuracy and Hardware Efficiency of Convolutional Capsule Networks. InProceedings of the IEEE/ACM International Conference on Computer-Aided Design (ICCAD ’20). doi:10.114...

    arXiv 2020

  18. [18]

    Alberto Marchisio, Vojtech Mrazek, Andrea Massa, Beatrice Bussolino, Maurizio Martina, and Muhammad Shafique. 2022. RoHNAS: A Neural Architecture Search Framework with Conjoint Optimization for Adversarial Robustness and Hardware Efficiency of Convolutional and Capsule Networks.IEEE Access(2022)

    2022

  19. [19]

    Darya Martyniuk, Johannes Jung, and Adrian Paschke. 2024. Quantum architec- ture search: a survey. In2024 IEEE International Conference on Quantum Comput- ing and Engineering (QCE), Vol. 1. IEEE, 1695–1706

    2024

  20. [20]

    Scherer, René Schwonnek, Elias F

    Nico Meyer, Daniel D. Scherer, René Schwonnek, Elias F. Combarro, and Frank K. Wilhelm. 2024. Qiskit-Torch-Module: Fast Prototyping of Quantum Neural Net- works. InIEEE International Conference on Quantum Computing and Engineering (QCE). doi:10.1109/QCE60285.2024.10821

    arXiv 2024

  21. [21]

    Vojtech Mrazek and Zdenek Vasicek. 2017. Parallel optimization of transistor level circuits using cartesian genetic programming. InProceedings of the Genetic and Evolutionary Computation Conference Companion(Berlin, Germany)(GECCO ’17). Association for Computing Machinery, New York, NY, USA, 1849–1856. doi:10.1145/3067695.3084212

    arXiv 2017

  22. [22]

    NVIDIA. 2026. CUDA-Q. https://nvidia.github.io/cuda-quantum

    2026

  23. [23]

    David Peral-García, Juan Cruz-Benito, and Francisco José García-Peñalvo. 2024. Systematic literature review: Quantum machine learning and its applications. Computer Science Review51 (2024), 100619. doi:10.1016/j.cosrev.2024.100619

    arXiv 2024

  24. [24]

    Nils Quetschlich et al. 2023. MQT Bench: Benchmarking Software and Design Automation Tools for Quantum Computing.Quantum(2023)

    2023

  25. [25]

    Gerhard Stenzel, Sebastian Zielinski, Michael Kölle, Philipp Altmann, Jonas Nüßlein, and Thomas Gabor. 2025. Qandle: Accelerating State Vector Simulation Using Gate-Matrix Caching and Circuit Splitting. InProceedings of the 17th International Conference on Agents and Artificial Intelligence - Volume 1: QAIO. INSTICC, SciTePress, 715–723. doi:10.5220/00133...

    work page doi:10.5220/0013343500003890 2025

  26. [26]

    Yasunari Suzuki et al. 2021. Qulacs: a fast and versatile quantum circuit simulator for research purpose.Quantum5 (2021), 559. doi:10.22331/q-2021-10-06-559

    doi:10.22331/q-2021-10-06-559 2021

  27. [27]

    Hanrui Wang et al. 2022. TorchQuantum Case Study for Robust Quantum Circuits. InICCAD

    2022

  28. [28]

    Kamila Zaman, Alberto Marchisio, Muhammad Abdullah Hanif, and Muham- mad Shafique. 2025. A Survey on Quantum Machine Learning: Current Trends, Challenges, Opportunities, and the Road Ahead. arXiv:2310.10315 [quant-ph] https://arxiv.org/abs/2310.10315

    Pith/arXiv arXiv 2025

  29. [29]

    Shi-Xin Zhang et al. 2023. TensorCircuit: a Quantum Software Framework for the NISQ Era.Quantum7 (2023), 912

    2023

  30. [62]

    doi:10.1038/s41534-022-00570-y

    doi:10.1038/s41534-022-00570-y

  31. [2025]

    2025), 103605

    Hybrid quantum-classical deep learning framework for balanced mul- ticlass diabetic retinopathy classification.MethodsX15 (Dec. 2025), 103605. doi:10.1016/j.mex.2025.103605

    arXiv 2025