Pith. sign in

REVIEW 1 major objections 4 minor 39 references

RASP-QAOA: Resource-Aware Per-Instance Selection for Exact QAOA Simulation

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

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

Pith's one-line read The paper claims that exact QAOA simulation should be chosen as a complete executable action, and that a compatibility-first selector covers all 31 solvable fresh-test requests and ranks first or second in all 31.

desk verdict Solid, honest empirical study of per-instance action selection for exact QAOA simulation; the load-bearing memory-compatibility model needs a false-negative audit before the coverage numbers are taken at face value. read the letter →

arxiv 2608.05646 v1 pith:ONOGPJPC submitted 2026-08-06 cs.ET cs.LG

Chih-Chung Hsu This is my paper · ORCID
classification cs.ETcs.LG
keywords QAOAsimulationper-instancealgorithmselectionresource-awareexactrepresentationmemorycompatibilitylearnedportfolioanalyticalworkestimates
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

Exact simulation of the quantum approximate optimization algorithm (QAOA) can run on very different computational representations—full state vectors, tensor contraction, causal-neighborhood evaluators, fixed-weight subspaces—whose feasible regions depend on graph structure, depth, precision, and memory. This paper argues that choosing a "backend name" is too coarse to make that decision, because the executable choice also fixes the representation, adapter, precision mode, and memory policy. It introduces RASP-QAOA, a two-stage selector that first prunes the candidate set by semantic, precision, deployment, and memory compatibility, then ranks the survivors with instance features when available and analytical work estimates otherwise. On a content-disjoint 60-request H200 test at $n\leq 35$, $p\leq 5$, it covers all 31 requests for which at least one admissible action completes and validates, ranks first or second in all 31, and obtains a failure-penalized score 0.0396 times that of the development-selected full-state baseline. A structural crossover shows the ordering gains come from graph-structure features, not from classifier complexity.

What carries the argument

The central object is the complete executable action key $a=(i,\kappa)$: a representation–adapter identity paired with a configuration that fixes precision, memory policy, and execution flags. It carries the argument because compatibility is decided at this key level—two full-state actions with different precision modes have different memory envelopes and numerical guarantees, and a fixed-weight implementation exists only when the mixer preserves the relevant subspace. The mechanism is the two-stage decomposition: the compatibility predicate $A_a(x)=S\wedge P\wedge D\wedge M$ defines the candidate set $C(x)$ using only pre-execution information (circuit checks, precision checks, deployment checks, and calibrated peak-memory estimates such as a calibrated process base plus per-amplitude bytes for full-state actions and a contraction boundary for tensor contraction), and the ordering stage applies the priority rule that feature-ranked actions from the learned support $D(x)=C(x)\cap \mathcal{A}_\phi$ are chosen when available, with analytical work proxies ordering compatible actions outside that support. This decomposition separates the question of which representations may compete from the question of which should be tried first.

What would settle it

Take the 60 fresh requests and re-run the selector while perturbing the calibrated memory coefficients within their calibration uncertainty (for example, varying the fixed process base around 768 MiB and the per-amplitude byte counts by ±10%), and check whether the 31-request oracle set and the 31/31 coverage partition remain unchanged. Separately, on the ten requests with compatible candidates but no strict completion, raise the execution cap and memory budget for those candidate actions; if any then completes and validates, the original compatibility model would have misclassified a feasible action as infeasible under the stated budget.

Watch

Extended reading notes

Core claim

The paper's central claim is that per-instance selection over complete executable action keys—not backend names—is the right formulation for exact QAOA simulation in the $n\leq 35$, $p\leq 5$ regime it tests. An action key $a=(i,\kappa)$ pairs a representation–adapter identity with a configuration fixing precision, memory policy, and execution flags; the compatibility predicate $A_a(x)=S\wedge P\wedge D\wedge M$ blocks actions that cannot implement the requested semantics, precision, deployment, or memory budget. The selector's rule prioritizes the intersection of the compatible set with the learned-support set $D(x)=C(x)\cap \mathcal{A}_\phi$, using a 30-dimensional request descriptor, and falls back to representation work proxies ($p\binom{n}{k}$ for fixed-weight simulation, $m^{O(dp)}$ for local evaluation, contraction-width terms for tensor methods, and $2^n$-scaling terms for full state) when no learned-supported action survives. On the fresh test the policy completes every one of the 31 oracle-solvable requests, reaches top-1 on 27 and top-2 on all 31, with 1.051 geometric-mean regret; the four top-1 misses are successful selections in the second 5% timing-equivalent group. The crossover result—structural features change 16 of 30 decisions and a depth-1 stump matches gradient boosting—supports the conclusion that the gains belong to representation-aware compatibility and instance features rather than to classifier sophistication.

Load-bearing premise

The load-bearing premise is that the calibrated pre-execution memory model—a fixed process base plus a per-amplitude byte count for full-state actions and a contraction boundary for tensor contraction—predicts which actions can actually complete; errors in those coefficients would change the candidate set, and the ten requests with candidates but no completion show the prediction is not already exact.

Editorial extensions

If this is right

  • QAOA tooling should expose action keys—representation, adapter, precision, memory policy—rather than backend names, since compatibility and cost can change while the backend name stays fixed.
  • A new simulator representation can enter the portfolio before any timing data is collected: compatibility checks plus a representation work proxy give it an analytical ordering, and it moves into learned support only after development observations.
  • Coverage and ranking are separate metrics: a selector can cover every solvable request while still sitting in the second timing group on 4 of 31 requests, so evaluation should report both.
  • Reported rankings are tied to a deployment horizon; cold start, eight-use amortization, and steady state can change which action is fastest, so fair comparison must state the reuse assumption.
  • The demonstrated regime is exact expectation-value simulation at $n\leq 35$, $p\leq 5$ on the tested GPU stack; other objectives, mixers, approximate methods, or hardware require their own action definitions, validation conditions, and timing calibration.

Reading between the lines

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

  • The compatibility-first action-key recipe is a general pattern for numerical toolchains: prune by exact semantic and resource constraints before any learned ranking, and keep an analytical fallback for out-of-support candidates; it should transfer beyond QAOA to any simulator ecosystem with multiple precision and memory modes.
  • The stability of the candidate set under repeated timeouts suggests the ten candidate-without-completion requests are genuine resource or implementation limits, so the next practical gain will come from adding a new representation for sparse/dense or fixed-cardinality regimes rather than from a better ranker.
  • Because a depth-1 structural stump reproduces the gradient-boosting decisions on the crossover, the ordering signal is probably captured by a few thresholds on graph-structural features; an interpretable rule could be extracted and tested on broader instance families.
  • The paper's explicit scope boundary invites a natural test: run the same action-key selection at $n=36$–$40$ on the same GPU stack to see whether the calibrated memory coefficients still predict the candidate set, or whether the per-amplitude memory base changes with problem size.
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

1 major / 4 minor

Summary. The paper formulates exact QAOA simulation selection as choosing among ten complete executable actions, each specified by a representation, adapter, precision mode, and memory policy. RASP-QAOA first filters actions using semantic, precision, deployment, and memory compatibility, then orders the surviving actions by learned scores when they are in a fixed development support, or by analytical work estimates otherwise. On a fresh 60-request H200 test it reports 31/31 coverage of the oracle-solvable requests, 27/31 top-1, 31/31 top-2, geometric-mean regret 1.051, and a failure-penalized PAR10 score 0.0396 times that of development-selected CUAOA. A separate 30-request crossover with overlapping actions tests whether structural features improve ordering. The paper concludes that resource-aware representation selection is valuable for exact QAOA simulation at n <= 35, p <= 5.

Significance. If the headline results hold, the paper makes a useful empirical contribution: it demonstrates a clean decomposition of simulator selection into compatibility filtering, learned ordering, analytical fallback, and separate validation, and it evaluates this decomposition on a content-disjoint fresh test. The strengths are the explicit action-key formulation, the repeated timeout checks, bootstrap intervals with the request as the independent unit, the deployment-horizon sensitivity analysis, and the authors' transparency about the single-action learned support and the secondary status of the earlier benchmark. The main limitation is that the central evaluation conditions on the same compatibility predicate used by the selector, so the headline coverage and ranking counts are exactly as strong as the calibrated memory model's false-negative behavior, which is not audited.

major comments (1)
  1. [§4.2, §6.1, §6.3] Because all 40 development labels are CUAOA, A_phi is the singleton {cuaoa_gpu}, so on the 60-request fresh test the learned branch D(x)=C(x)∩A_phi contains at most one action. The 19 learned-path successes are therefore compatibility-driven CUAOA selection, not evidence of learned ranking among competing actions. All direct evidence for feature-based per-instance ordering comes from the 30-request crossover with n=20, p=2 and three overlapping actions. This is a real scope limitation on the central 'per-instance selection' claim: the broad test validates portfolio construction and analytical fallback, while the ordering claim rests on a single fixed-(n,p) crossover. The authors are transparent about this, but the abstract and introduction could mislead; I recommend either adding multi-action regions to the fresh test or explicitly stating in the abstract that feature-based ordering is validated only in the controlled crossover region.
minor comments (4)
  1. [§5, Table 2] Please specify explicitly whether the normalized per-request PAR10 ratios are computed over all 60 requests or only over the 31 oracle-solvable requests; the current text can be read either way, and the interpretation of the 0.0396 figure depends on it.
  2. [§5] Clarify how the nine independent exact checks map onto the 31 oracle-solvable requests; if they cover only a subset, state which validation criterion is used for the remaining requests and whether cross-action agreement alone is considered sufficient.
  3. [§4.1] The exact coefficients of the memory-compatibility model appear only in the supplement; since C(x) is the central predicate, please include them in the main text or in a versioned code artifact so that the false-negative audit can be reproduced independently.
  4. [§6.3] The claim that a depth-1 structural stump exactly matches gradient boosting is reported without a confidence interval or resampling summary; on a 30-request sample, please report the stability of this exact match, for example by bootstrapping the decision agreement.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the fresh evaluation is content-disjoint, the validation oracle is independently grounded, and the analytical estimates are derived from complexity expressions rather than fitted to the headline metrics.

full rationale

The paper's central claims are self-contained against external evidence rather than being forced by construction. The fresh 60-request test is explicitly content-disjoint from development and calibration: "Request identifiers, generator seeds, and circuit content are disjoint from the 40-request development split, the earlier benchmark, and adapter calibration." The validation oracle does not reduce to the policy's own choices: it uses "cross-action agreement and nine independent exact checks" to validate the 31 oracle-solvable requests, and success is defined by observed completion and validation (Y = A ∧ R ∧ V), not merely by compatibility. The analytical ordering branch uses complexity-based work proxies such as p*C(n,k) and p*2^n, which are stated as "an ordering, not a guarantee of completion," not as fitted predictions of the reported regret or coverage. The only calibrated component is the pre-execution memory estimator in Section 4.1, whose coefficients are delegated to the supplement and calibrated on separate adapter-calibration data; the paper even downgrades its earlier 120-request set because "29 of its identifiers were used during adapter calibration." A remaining validation gap — that the false-negative rate of the memory estimator is not audited, while the same compatibility predicate A_a defines both the policy candidate set and the oracle-solvable denominator — is a robustness concern, not a circular reduction, because coverage still requires the selected action to actually return and validate, and the policy is executed independently of the oracle. No self-citation chain, renamed known result, or fitted-input-as-prediction pattern is present.

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

The central claims rest on calibrated memory and work-proxy constants and on the assumption that compatibility can be decided pre-execution. No new physical entities are introduced; the action key is a modeling construct, not a postulated entity.

free parameters (5)
  • Full-state memory model process base = 768 MiB
    Section 4.1: compatibility uses a calibrated peak-memory estimate with 768 MiB process base plus action-specific bytes per amplitude; changing this constant alters C(x) and coverage.
  • Action-specific memory bytes per amplitude = CUAOA 36 B/amplitude, Aer 24 B/amplitude, complex128 state 16 B/component
    Table 1 and Section 4.1: these calibrated envelopes decide which full-state actions fit within the request memory budget.
  • QTensor calibrated contraction boundary = Not stated in main text
    Section 4.1: QTensor uses a calibrated contraction boundary; the exact value is deferred to the supplement.
  • Tensor contraction work proxy coefficient and saturation = 1/4 p^2 min(n,28)
    Section 4.2: the analytical path ranks the tensor action with this proxy; the constants are chosen by hand or calibration.
  • Local evaluator work proxy constants = m^2 min(24,2+dp)
    Section 4.2: analytical proxy for local evaluator ordering, with constants chosen by hand.
assumptions (4)
  • domain assumption Pre-execution compatibility checks (semantic, precision, deployment, memory) can decide C(x) without execution
    Section 4.1 bases the entire candidate set on these checks; incorrect memory estimates would change coverage and top-k.
  • domain assumption The analytical work proxies are monotonically related to canonical runtime within the tested regime
    Section 4.2 uses these proxies to order actions outside learned support; if the proxies misorder, the analytical-path top-1 result changes.
  • domain assumption The validation oracle (cross-action agreement and nine independent exact checks) correctly labels strict completions
    Section 5: validity of the 31 oracle-solvable requests depends on these checks, whose details are not in the main text.
  • domain assumption The H200 deployment protocol (reuse horizon h=8, 300s cap, five processes) is the intended evaluation regime
    Headline numbers are tied to this protocol; the paper shows steady-state timing changes top-1 from 27/31 to 19/31.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RASP-QAOA: Resource-Aware Per-Instance Selection for Exact QAOA Simulation." pith.science (2026). https://pith.science/paper/ONOGPJPC

@misc{pith2026260805646,
  author       = {Pith},
  title        = {Pith review of: RASP-QAOA: Resource-Aware Per-Instance Selection for Exact QAOA Simulation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ONOGPJPC}},
  note         = {Machine review of arXiv:2608.05646}
}
read the original abstract

Exact QAOA simulation spans several computational representations whose useful regions differ sharply across graph structure, circuit depth, precision, and available memory. Choosing only a backend name hides these differences: an executable choice also fixes the representation, adapter, precision mode, and memory policy. We introduce RASP-QAOA, a per-instance selector over ten such actions. It first removes actions that cannot implement the requested QAOA semantics or execution requirements, then orders the remaining actions using instance features; actions outside learned support are handled by analytical work estimates. On a content-disjoint 60-request H200 evaluation, RASP-QAOA succeeds on all 31 requests for which at least one admissible action completes and validates. Within this set it reaches 27/31 top-1 and 31/31 top-2 selection, with 1.051 geometric-mean regret. Its failure-penalized PAR10 score is 0.0396 times that of development-selected CUAOA (95% interval: 0.0085-0.1644). A separate 30-request crossover shows that graph structure changes 16 decisions and improves the paired penalized score, while a depth-1 stump matches gradient boosting. The evidence supports resource-aware representation selection at n <= 35, p <= 5, with gains driven by representation features rather than classifier complexity.

Figures

Figures reproduced from arXiv: 2608.05646 by the authors.

Figure 1
Figure 1. Decision structure of RASP-QAOA. The request is checked against the semantic, precision, deployment, and memory conditions of every complete action key. Surviving actions form C(x). Actions in the fixed development support Aϕ are feature￾ranked; when none survive, representation-specific work estimates order C(x), recovering 12/31 oracle-solvable fresh requests. Execution is evaluated separately by Y = A ∧ R ∧ V . w… view at source ↗
Figure 2
Figure 2. Policy comparison on the 31 oracle-solvable fresh requests. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Portfolio reach and conditional ranking. (a) Among all 60 fresh requests, 19 have no compatible action, 10 have one or more candidates but no strict completion, and 31 are oracle-solvable; RASP-QAOA covers all 31. (b) On this 31-request set, top-2 covers every request in all three regimes, while top-1 is 14/15, 8/8, and 5/8. n, p only Full features Structural stump 0 5 10 15 20 25 30 35 Requests 27/30 30/30 30/30 12… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Structure-aware ordering on the 30-request crossover. (a) Full features raise coverage from 27/30 to 30/30 and top-1 from 12/30 to 25/30; a structural stump matches gradient boosting. (b) Full features yield 16 paired wins, 14 ties, and no losses against n, p-only orde…
Figure 5
Figure 5. Figure 5: Matched H100/RTX 3090 measurements for two internal full-state actions. Runtime components differ enough to [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 37 canonical work pages

  1. [1]

    2014 , eprint =

    A Quantum Approximate Optimization Algorithm , author =. 2014 , eprint =

    work page 2014

  2. [2]

    Frontiers in Physics , volume =

    Ising Formulations of Many NP Problems , author =. Frontiers in Physics , volume =. 2014 , doi =

    work page 2014

  3. [3]

    Physics Reports , volume =

    A Review on Quantum Approximate Optimization Algorithm and Its Variants , author =. Physics Reports , volume =. 2024 , doi =

    work page 2024

  4. [4]

    Algorithms , volume =

    From the Quantum Approximate Optimization Algorithm to a Quantum Alternating Operator Ansatz , author =. Algorithms , volume =. 2019 , doi =

    work page 2019

  5. [5]

    Advances in Computers , volume =

    The Algorithm Selection Problem , author =. Advances in Computers , volume =. 1976 , doi =

    work page 1976

  6. [6]

    AI Magazine , volume =

    Algorithm Selection for Combinatorial Search Problems: A Survey , author =. AI Magazine , volume =. 2014 , url =

    work page 2014

  7. [7]

    Evolutionary Computation , volume =

    Automated Algorithm Selection: Survey and Perspectives , author =. Evolutionary Computation , volume =. 2019 , doi =

    work page 2019

  8. [8]

    and Hutter, Frank and Schaub, Torsten , journal =

    Lindauer, Marius and Hoos, Holger H. and Hutter, Frank and Schaub, Torsten , journal =. 2015 , doi =

    work page 2015

Show all 39 references
  1. [9]

    Fast Simulation of High-Depth

    Lykov, Danylo and Shaydulin, Ruslan and Sun, Yue and Alexeev, Yuri and Pistoia, Marco , booktitle =. Fast Simulation of High-Depth. 2023 , doi =

    2023

  2. [10]

    Stein, Jonas and Blenninger, Jonas and Bucher, David and Eder, Peter J. and. 2024 IEEE International Conference on Quantum Computing and Engineering (QCE) , pages =. 2024 , doi =

    2024

  3. [11]

    Performance Evaluation and Acceleration of the

    Lykov, Danylo and Chen, Angela and Chen, Huaxuan and Keipert, Kristopher and Zhang, Zheng and Gibbs, Tom and Alexeev, Yuri , booktitle =. Performance Evaluation and Acceleration of the. 2021 , doi =

    2021

  4. [12]

    2023 , doi =

    Golden, John and Baertschi, Andreas and O'Malley, Dan and Pelofske, Elijah and Eidenbenz, Stephan , booktitle =. 2023 , doi =

    2023

  5. [13]

    2025 , doi =

    Venev, Hristo and Udomsrirungruang, Thien and Dimitrov, Dimitar and Gehr, Timon and Vechev, Martin , journal =. 2025 , doi =

    2025

  6. [14]

    2026 , howpublished =

    2026

  7. [15]

    and Leyton-Brown, Kevin , journal =

    Xu, Lin and Hutter, Frank and Hoos, Holger H. and Leyton-Brown, Kevin , journal =. 2008 , doi =

    2008

  8. [16]

    and Leyton-Brown, Kevin , journal =

    Xu, Lin and Hoos, Holger H. and Leyton-Brown, Kevin , journal =. 2010 , doi =

    2010

  9. [17]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Deep Learning for Algorithm Portfolios , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2016 , doi =

    2016

  10. [18]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Automatic Construction of Parallel Portfolios via Explicit Instance Grouping , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2019 , doi =

    2019

  11. [19]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Online Planner Selection with Graph Neural Networks and Adaptive Scheduling , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2020 , doi =

    2020

  12. [20]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Generalization in Portfolio-Based Algorithm Selection , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2021 , doi =

    2021

  13. [21]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Machine Learning for Online Algorithm Selection under Censored Feedback , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2022 , doi =

    2022

  14. [22]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Explainable Planner Selection for Classical Planning , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2022 , doi =

    2022

  15. [23]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Automatic Selection of Macro-Events for Heuristic-Search Temporal Planning , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2025 , doi =

    2025

  16. [24]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Learning to Optimize Variational Quantum Circuits to Solve Combinatorial Problems , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2020 , doi =

    2020

  17. [25]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Training-Free Quantum Architecture Search , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2024 , doi =

    2024

  18. [26]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Relational Verification for Cost-Aware Quantum Program Optimization , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2026 , doi =

    2026

  19. [27]

    Bayraktar, Harun and Charara, Ali and Clark, David and Cohen, Saul and Costa, Timothy and Fang, Yao-Lung L. and Gao, Yang and Guan, Jack and Gunnels, John and Haidar, Azzam and Hehn, Andreas and Hohnerbach, Markus and Jones, Matthew and Lubowe, Tom and Lyakh, Dmitry and Morino...

    2023

  20. [28]

    2025 , doi =

    Zhang, Boyuan and Fang, Bo and Ye, Fanjiang and Guo, Luanzheng and Song, Fengguang and Tallent, Nathan and Tao, Dingwen , booktitle =. 2025 , doi =

    2025

  21. [29]

    2025 , doi =

    Jiang, Shui and Chung, Yi-Hua and Chang, Chih-Chun and Ho, Tsung-Yi and Huang, Tsung-Wei , booktitle =. 2025 , doi =

    2025

  22. [30]

    2409.14697 , archivePrefix =

    Wang, Chuan-Chi , year =. 2409.14697 , archivePrefix =

    arXiv

  23. [31]

    ACM Transactions on Quantum Computing , volume =

    Simulation of Quantum Computers: Review and Acceleration Opportunities , author =. ACM Transactions on Quantum Computing , volume =. 2026 , doi =

    2026

  24. [32]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Algorithm Selection via Ranking , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2015 , doi =

    2015

  25. [33]

    Proceedings of the AAAI Conference on Artificial Intelligence , volume =

    Online Prompt Selection for Program Synthesis , author =. Proceedings of the AAAI Conference on Artificial Intelligence , volume =. 2025 , doi =

    2025

  26. [34]

    Leskovec, Jure and Krevl, Andrej , title =

  27. [35]

    Artificial Intelligence , volume =

    Bischl, Bernd and Kerschke, Pascal and Kotthoff, Lars and Lindauer, Marius and Malitsky, Yuri and Fr. Artificial Intelligence , volume =. 2016 , doi =

    2016

  28. [36]

    2021 , doi =

    Liu, Tong and Amadini, Roberto and Gabbrielli, Maurizio and Mauro, Jacopo , journal =. 2021 , doi =

    2021

  29. [37]

    2503.06233 , archivePrefix =

    Liaqat, Amana and Darwish, Ahmed and Roman, Adrian and DiAdamo, Stephen , year =. 2503.06233 , archivePrefix =

    arXiv

  30. [38]

    2025 , eprint =

    Maestro: Intelligent Execution for Quantum Circuit Simulation , author =. 2025 , eprint =

    2025

  31. [39]

    2604.03816 , archivePrefix =

    Kumaresan, Poornima and Muruganantham, Pavithra and Rajendran, Lakshmi and Sivasubramani, Santhosh , year =. 2604.03816 , archivePrefix =

    arXiv

Pith tools

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