Pith. sign in

REVIEW 3 major objections 5 minor 43 references

QCOR: A Language Extension Specification for the Heterogeneous Quantum-Classical Model of Computation

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read QCOR proposes a single-source C/C++ language extension that compiles hybrid quantum-classical programs, with asynchronous quantum tasks and high-level abstractions for observables, objective functions, and optimizers.

desk verdict A clear design proposal for a C/C++ quantum-classical language extension that doesn't deliver the specification it promises—syntax and execution semantics are deferred to future implementors, so the compiled-binary claim is unsupported. read the letter →

arxiv 1909.02457 v1 pith:MFAPQ5JM submitted 2019-09-05 cs.PL quant-ph

classification cs.PLquant-ph
keywords quantumcomputingheterogeneousprogrammingmodelspecificationNISQhybridquantum-classicalcomputationC++languageextensionasynchronousexecution
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 argues that near-term quantum hardware is too noisy to run standalone algorithms, so the practical path is heterogeneous quantum-classical computation in which a classical host drives a quantum coprocessor. To make that division of labor programmable, it introduces QCOR, a specification that extends C and C++ with library calls and compiler directives for expressing quantum kernels, observables, objective functions, and optimizers in a single source file. The central claim is that programs written under this specification can be compiled into working hybrid binaries that launch quantum tasks asynchronously and synchronize on results later. The payoff would be a vendor-neutral programming model that lets HPC-style developers write variational, iterative, and feed-forward quantum algorithms without manual circuit bookkeeping or remote-job orchestration.

What carries the argument

The load-bearing mechanism is the taskInitiate/sync execution pair embedded in a discrete memory model. taskInitiate takes a quantum kernel plus optional Observable, ObjectiveFunction, and Optimizer, composes the required measurement and optimization workflow, returns immediately with a handle, and lets the host run in parallel with the quantum device; sync waits on the handle and returns a ResultBuffer tree holding all measurement results and metadata. Around this pair sit the data abstractions—Observable, ObjectiveFunction, Optimizer, ResultBuffer—whose defaults make the same call express a bare expectation value or a complete variational optimization. The discrete memory model keeps host and quantum memory separate, with explicit host-side library calls for data movement and compiler-managed allocation on the quantum side.

What would settle it

Build a QCOR program that uses taskInitiate followed immediately by classical work, run it on a backend whose submission API is synchronous, and time the return of taskInitiate: if it blocks until the quantum job completes, the asynchrony guarantee at the center of the execution model is false. A portability check is equally direct: the same source, without vendor-specific code, must compile and run on two different quantum backends.

Watch

Extended reading notes

Core claim

The paper's central claim is that the hybrid quantum-classical model of computation can be captured by a small set of abstractions and two execution calls. An Observable maps an unmeasured quantum kernel to measured circuits; an ObjectiveFunction evaluates a scalar function of parameters by running those measured circuits; an Optimizer updates the parameters; and a ResultBuffer stores measurement counts and execution metadata, composeable into a tree that spans all iterations. The taskInitiate call launches this entire workflow on the quantum coprocessor and immediately returns a handle, allowing the host to continue other work; the sync call blocks until the objective function terminates and returns the ResultBuffer. With defaults filling in missing arguments, the same call shape covers simple expectation-value evaluation, full variational optimization, and layered error-mitigation via ObjectiveFunction decoration. The paper claims that this single-source, asynchronous, host-directed model is sufficient for variational, iterative, and feed-forward quantum computing.

Load-bearing premise

The load-bearing premise is that a quantum device can accept asynchronous task submission—that taskInitiate returns immediately while the quantum job runs—since the specification itself observes that existing frameworks use loosely coupled remote submission and leaves the concrete runtime to implementors.

Editorial extensions

If this is right

  • A QCOR program expresses a variational quantum eigensolver in a few lines of C++ without explicit circuit bookkeeping, and the same source compiles to a binary that drives the quantum backend.
  • Error mitigation becomes a compositional layer: decorating an ObjectiveFunction with a mitigation ObjectiveFunction wraps the algorithm in pre- and post-processing with no change to the core logic.
  • The same taskInitiate call, through defaults, covers the full range from a single expectation-value evaluation to optimizer-driven VQE iteration, giving one uniform asynchronous API.
  • Multiple taskInitiate calls can run concurrently, enabling data-level, measurement-basis-level, and task-level parallelism in a single program.
  • The discrete memory model lets QCOR target both shared and distributed host-quantum memory configurations, aligning with HPC practice.

Reading between the lines

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

  • If asynchronous task submission becomes standard, QCOR-style directives could evolve the same way GPU-offload pragmas did, letting the compiler hide device details behind a stable host-facing API.
  • A concrete test of the specification would be to compile the same VQE source with two independent QCOR implementations targeting different backends and check that the program logic, defaults, and ResultBuffer handling remain unchanged.
  • The defaults in taskInitiate imply a natural batching strategy: one optimization step splits into parallel basis measurements, so a QCOR runtime could distribute those measurements across QPUs without changing user code.
  • The specification leaves feed-forward control at the level of 'in principle'; a direct extension would be to define measurement-conditioned gates explicitly, which the current data structures only hint at.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper introduces QCOR, a proposed library- and directives-based language extension for single-source, heterogeneous quantum-classical programming in C/C++. It defines a programming model in which quantum kernels are expressed as high-level library calls and directives; a discrete memory model with explicit host-side memory management; a set of core data structures (Observable, ObservableTransform, ResultBuffer, ObjectiveFunction, Optimizer); and an asynchronous execution model based on taskInitiate and sync library calls. The manuscript illustrates the approach with code snippets for a variational quantum eigensolver, for taskInitiate variants with default arguments, and for error mitigation through ObjectiveFunction decoration. The central claim, stated in the abstract, is that programs written with QCOR 'can be compiled to produce functional hybrid binary executables.'

Significance. If the QCOR specification were fully realized, it would offer a vendor-agnostic, HPC-oriented programming model for near-term hybrid quantum-classical algorithms, raising the level of abstraction above circuit construction to observables, objective functions, and optimizers. The paper's conceptual distillation of hybrid algorithms into these core abstractions is useful, and the proposed ObjectiveFunction-decoration pattern for automated error mitigation is a clean and extensible design. The work builds transparently on the authors' XACC framework, which is cited and acknowledged, so the concern about circular reasoning does not arise: this is a dependency on prior work rather than an uncited reuse. No numerical claims or fitted parameters are involved, so the usual circular-fitted-value concern is also absent. The main risk is completeness: the document is titled and abstracted as a specification, but it explicitly defers the definition of the language it names, leaving no way for a third party to write or compile a QCOR program from the text.

major comments (3)
  1. [§4.3.1, §4.4, and Abstract] The central claim is not supported because the paper does not actually specify the language extension it names. Section 4.3.1 states that 'our specification leaves the exact definition and expression of a quantum code to concrete QCOR language extension implementors,' and Section 4.4 similarly defers 'the exact nature of the implementation of these quantum-classical parallel computing paradigms to concrete QCOR language extensions.' No concrete syntax is given for the directives, no signatures are given for taskInitiate or sync, and the methods of Observable, ObjectiveFunction, Optimizer, and ResultBuffer are described only conceptually. Figure 6 relies on an implementation-specific 'kernel' placeholder, and Section 6 states that the prototype is based on 'a concrete implementation of QCOR that is underway.' A third party cannot, from this paper alone, write a QCOR program or produce a hybrid binary, contradicting the abstract's assertion that such programs 'can be compiled to produce functional hybrid binary executables.' This is an internal completeness gap, not merely a disagreement with community consensus, because the paper itself admits the deferred parts. I recommend either providing the missing concrete specification or explicitly reframing the paper as a design proposal and softening the abstract accordingly.
  2. [§4.4 and §2.4] The execution model's core mechanism, in which taskInitiate 'immediately upon invocation... returns a handle object' and the host continues executing while the quantum task runs asynchronously, presupposes non-blocking, asynchronous submission support in both the runtime and the backend hardware. The paper's own survey of existing frameworks in Section 2.4 describes them as 'loosely coupled' REST-based execution, and the specification leaves implementation details to concrete QCOR extensions. The authors should provide a concrete test of this assumption, for example by giving a minimal runtime interface (a job-submission call and a synchronization primitive) and mapping it to at least one existing backend or simulator, or by qualifying the asynchrony guarantee as a design target rather than a property of the current specification.
  3. [§5, Fig. 6, §6] The demonstration section does not demonstrate compilation or execution: Figures 5–8 are illustrative code snippets that reference undefined types, methods, and an unspecified 'kernel' expression, and the paper states in Section 5 that it illustrates expressiveness 'without delving into implementation details.' Section 6 nevertheless claims that the snippets demonstrate 'overall efficiency with respect to existing approaches,' but no performance data or executed example is provided. If the paper is to remain a specification, the demonstration should include at least one fully defined, runnable example or a clear pointer to an implementation; the efficiency claim in Section 6 should either be removed or supported by measurements.
minor comments (5)
  1. [§2.3] The text contains a repeated and ungrammatical phrase: 'By design, it Q# does not define quantum states...' and 'It Q# is a strongly typed language...' should be 'By design, Q# does not define quantum states...' and 'Q# is a strongly typed language...'.
  2. [§2.2] The name 'Bernhard Omer' should be spelled 'Bernhard Ömer,' and reference [32] would benefit from a version or access date because the linked document may change.
  3. [§4.3.2] The example 'H = c†0c†1c0c1' uses non-ASCII superscript daggers that may not render correctly in all venues; a LaTeX expression or explicit creation/annihilation operator notation would improve clarity.
  4. [Fig. 6 and §4.3.1] The caption of Figure 6 says 'kernel here refers to an implementation-specific kernel expression like that in Figure 3 (top),' which is not a concrete definition. At minimum, the figure should show the exact kernel syntax used in the snippet rather than an undefined placeholder.
  5. [Abstract and §6] The abstract's phrase 'can be compiled to produce functional hybrid binary executables' is stronger than anything supported in the body; I suggest changing it to 'are intended to be compiled' or adding 'given a concrete implementation.' Similarly, Section 6's word 'efficiency' overstates what the illustrative snippets show; 'expressiveness' would be more accurate.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: QCOR is a design/specification paper with no fitted quantities, derived predictions, or self-cited uniqueness claims; its central content is a proposed API and execution model.

full rationale

QCOR does not claim to derive any numerical or empirical result, so the standard circularity patterns (fitted input called prediction, self-definitional formulas, uniqueness imported from authors) do not apply. The paper's contribution is a proposed language extension, and its load-bearing statements are programmatic design choices (single-source model, discrete memory spaces, taskInitiate/sync execution). The abstract's promise that QCOR programs 'can be compiled to produce functional hybrid binary executables' is not derived from the specification by construction; rather, it is an aspiration that the paper itself qualifies by leaving 'the exact definition and expression of a quantum code to concrete QCOR language extension implementors' (Sec. 4.3.1) and 'the exact nature of the implementation of these quantum-classical parallel computing paradigms to concrete QCOR language extensions' (Sec. 4.4). That is an under-specification/completeness gap, not circular reasoning. The reliance on the authors' own XACC framework [24] is real but is used as a comparative baseline and a source of execution concepts, not as an unexamined premise that forces the paper's conclusions. The prototype snippets in Section 5 are explicitly labeled 'prototype implementation' based on 'a concrete implementation of QCOR that is underway' (Sec. 6); they illustrate, rather than entail, the specification. No equation or fitted parameter is renamed as a prediction, and no prior result by the same authors is invoked to forbid alternatives. Accordingly, the appropriate circularity score is 0.

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

The specification rests on several domain assumptions about the target machine and implementor capabilities. No free parameters are fitted because there is no data. The design assumes an attached quantum co-processor with discrete memory, the availability of a heterogeneous map container, and an asynchronous task runtime; these are stated in Section 4 but not demonstrated. QCOR defines software abstractions (Observable, ObjectiveFunction, Optimizer, ResultBuffer, taskInitiate and sync) but no new physical entities.

assumptions (4)
  • domain assumption The target machine model places the quantum device as an attached co-processor with discrete host and quantum memory spaces.
    Figure 1 and Section 4.2 assume this architecture; the programming and memory models depend on it.
  • ad hoc to paper The host language (C/C++) can be extended with library calls and compiler directives that a compiler can recognize and offload as quantum kernels.
    Section 4.1 and Section 4.3.1 leave the definition of a quantum expression to implementors; this is a pivotal unproven premise for the claimed single-source compilation.
  • domain assumption A HeterogeneousMap associative array mapping string keys to variant values is available in the host language.
    Section 4.3.1 lists this as a precondition for implementors; the entire API relies on it.
  • ad hoc to paper taskInitiate returns a handle immediately and can execute asynchronously with respect to the host thread.
    Section 4.4 defines the execution model around this; no demonstration that vendor backends support non-blocking handles is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of QCOR: A Language Extension Specification for the Heterogeneous Quantum-Classical Model of Computation." pith.science (2026). https://pith.science/paper/MFAPQ5JM

@misc{pith2026190902457,
  author       = {Pith},
  title        = {Pith review of: QCOR: A Language Extension Specification for the Heterogeneous Quantum-Classical Model of Computation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MFAPQ5JM}},
  note         = {Machine review of arXiv:1909.02457}
}
read the original abstract

Quantum computing is an emerging computational paradigm that leverages the laws of quantum mechanics to perform elementary logic operations. Existing programming models for quantum computing were designed with fault-tolerant hardware in mind, envisioning standalone applications. However, near-term quantum computers are susceptible to noise which limits their standalone utility. To better leverage limited computational strengths of noisy quantum devices, hybrid algorithms have been suggested whereby quantum computers are used in tandem with their classical counterparts in a heterogeneous fashion. This {\it modus operandi} calls out for a programming model and a high-level programming language that natively and seamlessly supports heterogeneous quantum-classical hardware architectures in a single-source-code paradigm. Motivated by the lack of such a model, we introduce a language extension specification, called QCOR, that enables single-source quantum-classical programming. Programs written using the QCOR library and directives based language extensions can be compiled to produce functional hybrid binary executables. After defining the QCOR's programming model, memory model, and execution model, we discuss how QCOR enables variational, iterative, and feed forward quantum computing. QCOR approaches quantum-classical computation in a hardware-agnostic heterogeneous fashion and strives to build on best practices of high performance computing (HPC). The high level of abstraction in the developed language is intended to accelerate the adoption of quantum computing by researchers familiar with classical HPC.

Figures

Figures reproduced from arXiv: 1909.02457 by the authors.

Figure 1
Figure 1. Illustration of the target extreme scale, heterogeneous machine model [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Diagram of the QCOR memory model 4.3 Data Structures Here we describe the core data structures that are part of the QCOR language extension specifica￾tion for iterative, quantum-classical application expression. We begin by stating the assumptions , Vol. 1, No. 1, Article . Publication date: September 2019 [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Example of valid QCOR quantum kernels in C++ (top), C (middle), and Python (bottom). [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Diagram of QCOR Execution Model The taskInitiate call orchestrates and composes the workflow necessary to initialize the ObjectiveFunction and begin classical optimization of it through the provided Optimizer. The ObjectiveFunction evaluations, driven by the Optimizer,…
Figure 5
Figure 5. Figure 5: Implementation of a simple two-qubit variational quantum eigensolver algorithm using the lowest [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6: Prototype implementation of a simple two-qubit variational quantum eigensolver algorithm with the [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Prototype implementation demonstrating taskInitiate with default ObjectiveFunction and no Optimizer, taking a vector of kernel parameters [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 21 canonical work pages

  1. [1]

    [n. d.]. MPark.Variant. http://github.com/mpark/variant. ([n. d.]). Accessed: 2019-07-16

  2. [2]

    [n. d.]. New Language helps quantum coders build killer apps. https://www.newscientist.com/article/dn23820-new- language-helps-quantum-coders-build-killer-apps/. ([n. d.]). Accessed: 2019-03-07

  3. [3]

    [n. d.]. Rigetti Forest SDK Documentation. ([n. d.]). http://docs.rigetti.com/en/stable/

  4. [4]

    Millis, Matthew B

    Bela Bauer, Dave Wecker, Andrew J. Millis, Matthew B. Hastings, and Matthias Troyer. 2016. Hybrid Quantum-Classical Approach to Correlated Materials. Phys. Rev. X 6 (Sep 2016), 031045. Issue 3. https://doi.org/10.1103/PhysRevX.6.031045

  5. [5]

    Marcello Benedetti, Delfina Garcia-Pintos, Yunseong Nam, and Alejandro Perdomo-Ortiz. 2018. A generative modeling approach for benchmarking and training shallow quantum circuits. arXiv preprint arXiv:1801.07686 (2018)

  6. [6]

    Ajinkya Borle and Josh McCarter. 2019. On Post-Processing the Results of Quantum Optimizers. (may 2019). arXiv:1905.13107 http://arxiv.org/abs/1905.13107

  7. [7]

    J. I. Colless, V. V. Ramasesh, D. Dahlen, M. S. Blok, M. E. Kimchi-Schwartz, J. R. McClean, J. Carter, W. A. de Jong, and I. Siddiqi. 2018. Computation of Molecular Spectra on a Quantum Processor with an Error-Resilient Algorithm. Phys. Rev. X 8 (Feb 2018), 011021. Issue 1. https://doi.org/10.1103/PhysRevX.8.011021

  8. [8]

    Cross, Lev S

    Andrew W. Cross, Lev S. Bishop, John A. Smolin, and Jay M. Gambetta. 2017. Open Quantum Assembly Language. (2017). https://doi.org/10.1016/j.bbrc.2014.09.107 arXiv:1707.03429

Show all 43 references
  1. [9]

    E. F. Dumitrescu, A. J. McCaskey, G. Hagen, G. R. Jansen, T. D. Morris, T. Papenbrock, R. C. Pooser, D. J. Dean, and P. Lougovski. 2018. Cloud Quantum Computing of an Atomic Nucleus. Phys. Rev. Lett. 120 (May 2018), 210501. Issue 21. https://doi.org/10.1103/PhysRevLett.120.210501

  2. [10]

    Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. 2014. A quantum approximate optimization algorithm. arXiv preprint arXiv:1411.4028 (2014)

  3. [11]

    Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design Patterns: Elements of Reusable Object- oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA

  4. [12]

    Simon J. Gay. 2006. Quantum Programming Languages: Survey and Bibliography. Mathematical. Structures in Comp. Sci. 16, 4 (Aug. 2006), 581–600. https://doi.org/10.1017/S0960129506005378

  5. [13]

    Craig Gidney. 2018. Cirq and OpenFermion Hands On Tutorial. (Sept. 2018). https://doi.org/10.5281/zenodo.2880472

  6. [14]

    Green, Peter LeFanu Lumsdaine, Neil J

    Alexander S. Green, Peter LeFanu Lumsdaine, Neil J. Ross, Peter Selinger, and Benoît Valiron. 2013. An Introduction to Quantum Programming in Quipper. arXiv e-prints , Article arXiv:1304.5485 (Apr 2013), arXiv:1304.5485 pages. arXiv:cs.PL/1304.5485 , Vol. 1, No. 1, Article . P...

  7. [15]

    Green, Peter Selinger, Peter Lefanu Lumsdaine, BenoÃőt Valiron, and Neil J

    Alexander S. Green, Peter Selinger, Peter Lefanu Lumsdaine, BenoÃőt Valiron, and Neil J. Ross. 1304. Quipper: A Scalable Quantum Programming Language. (1304)

  8. [16]

    Chong, and Margaret Martonosi

    Ali JavadiAbhari, Shruti Patil, Daniel Kudrow, Jeff Heckey, Alexey Lvov, Frederic T. Chong, and Margaret Martonosi

  9. [17]

    Abhinav Kandala, Antonio Mezzacapo, Kristan Temme, Maika Takita, Markus Brink, Jerry M Chow, and Jay M Gambetta. 2017. Hardware-efficient variational quantum eigensolver for small molecules and quantum magnets. Nature 549 (sep 2017), 242. http://dx.doi.org/10.1038/nature23879h...

  10. [18]

    Nathan Killoran, Josh Izaac, Nicolás Quesada, Ville Bergholm, Matthew Amy, and Christian Weedbrook. 2019. Strawberry Fields: A Software Platform for Photonic Quantum Computing. Quantum 3 (mar 2019), 129. https: //doi.org/10.22331/q-2019-03-11-129

  11. [19]

    N Klco, EF Dumitrescu, AJ McCaskey, TD Morris, RC Pooser, M Sanz, E Solano, P Lougovski, and MJ Savage. 2018. Quantum-Classical Dynamical Calculations of the Schwinger Model using Quantum Computers. arXiv preprint arXiv:1803.03326 (2018)

  12. [20]

    Benjamin P Lanyon, James D Whitfield, Geoff G Gillett, Michael E Goggin, Marcelo P Almeida, Ivan Kassal, Jacob D Biamonte, Masoud Mohseni, Ben J Powell, Marco Barbieri, et al. 2010. Towards quantum chemistry on a quantum computer. Nature chemistry 2, 2 (2010), 106

  13. [21]

    Jun Li, Xiaodong Yang, Xinhua Peng, and Chang-Pu Sun. 2017. Hybrid Quantum-Classical Approach to Quantum Optimal Control. Phys. Rev. Lett. 118 (Apr 2017), 150503. Issue 15. https://doi.org/10.1103/PhysRevLett.118.150503

  14. [23]

    Benjamin

    Ying Li and Simon C. Benjamin. 2017. Efficient Variational Quantum Simulator Incorporating Active Error Minimization. Physical Review X 7, 2 (jun 2017), 021050. https://doi.org/10.1103/PhysRevX.7.021050

  15. [24]

    McCaskey, E.F

    A.J. McCaskey, E.F. Dumitrescu, D. Liakh, M. Chen, W. Feng, and T.S. Humble. 2018. A language and hardware independent approach to quantumÃćÂĂÂŞclassical computing. SoftwareX 7 (2018), 245 – 254. https://doi.org/10. 1016/j.softx.2018.07.007

  16. [25]

    McClean, Sergio Boixo, Vadim N

    Jarrod R. McClean, Sergio Boixo, Vadim N. Smelyanskiy, Ryan Babbush, and Hartmut Neven. 2018. Barren plateaus in quantum neural network training landscapes. (mar 2018). arXiv:1803.11173 http://arxiv.org/abs/1803.11173

  17. [26]

    Jarrod R McClean, Jonathan Romero, Ryan Babbush, and Alán Aspuru-Guzik. 2016. The theory of variational hybrid quantum-classical algorithms. New Journal of Physics 18, 2 (2016), 023023

  18. [27]

    McClean, Kevin J

    Jarrod R. McClean, Kevin J. Sung, Ian D. Kivlichan, Yudong Cao, Chengyu Dai, E. Schuyler Fried, Craig Gidney, Brendan Gimby, Pranav Gokhale, Thomas Häner, Tarini Hardikar, Vojtěch Havlíček, Oscar Higgott, Cupjin Huang, Josh Izaac, Zhang Jiang, Xinle Liu, Sam McArdle, Matthew N...

  19. [28]

    McKay, Thomas Alexander, Luciano Bello, Michael J

    David C. McKay, Thomas Alexander, Luciano Bello, Michael J. Biercuk, Lev Bishop, Jiayin Chen, Jerry M. Chow, Antonio D. Córcoles, Daniel Egger, Stefan Filipp, Juan Gomez, Michael Hush, Ali Javadi-Abhari, Diego Moreda, Paul Nation, Brent Paulovicks, Erick Winston, Christopher J...

  20. [29]

    Nikolaj Moll, Panagiotis Barkoutsos, Lev S Bishop, Jerry M Chow, Andrew Cross, Daniel J Egger, Stefan Filipp, Andreas Fuhrer, Jay M Gambetta, Marc Ganzhorn, et al. 2017. Quantum optimization using variational algorithms on near-term quantum devices. arXiv preprint arXiv:1710.0...

  21. [30]

    Nielson, Michael A

    Isaac L. Nielson, Michael A. and Chuang. 2001. Quantum Computation and Quantum Information (10th ed.). Cambridge University Press

  22. [31]

    P. J. J. O‘Malley, R. Babbush, I. D. Kivlichan, J. Romero, J. R. McClean, R. Barends, J. Kelly, P. Roushan, A. Tranter, N. Ding, B. Campbell, Y. Chen, Z. Chen, B. Chiaro, A. Dunsworth, A. G. Fowler, E. Jeffrey, E. Lucero, A. Megrant, J. Y. Mutus, M. Neeley, C. Neill, C. Quinta...

  23. [32]

    Bernhard Omer. [n. d.]. A Procedural Formalism for Quantum Computing. ([n. d.]). http://tph.tuwien.ac.at/~oemer/ doc/qcldoc.pdf

  24. [33]

    JS Otterbach, R Manenti, N Alidoust, A Bestwick, M Block, B Bloom, S Caldwell, N Didier, E Schuyler Fried, S Hong, et al. 2017. Unsupervised Machine Learning on a Hybrid Quantum Computer. arXiv preprint arXiv:1712.05771 (2017). , Vol. 1, No. 1, Article . Publication date: Sept...

  25. [34]

    Paesani, A

    S. Paesani, A. A. Gentile, R. Santagati, J. Wang, N. Wiebe, D. P. Tew, J. L. O’Brien, and M. G. Thompson. 2017. Experimental Bayesian Quantum Phase Estimation on a Silicon Photonic Chip. Phys. Rev. Lett. 118 (Mar 2017), 100503. Issue 10. https://doi.org/10.1103/PhysRevLett.118.100503

  26. [35]

    Alejandro Perdomo-Ortiz, Marcello Benedetti, John Realpe-Gómez, and Rupak Biswas. 2017. Opportunities and challenges for quantum-assisted machine learning in near-term quantum computers. arXiv preprint arXiv:1708.09757 (2017)

  27. [36]

    Alberto Peruzzo, Jarrod McClean, Peter Shadbolt, Man-Hong Yung, Xiao-Qi Zhou, Peter J Love, Alán Aspuru-Guzik, and Jeremy L O’Brien. 2014. A variational eigenvalue solver on a photonic quantum processor.Nature Communications 5 (jul 2014), 4213. http://dx.doi.org/10.1038/ncomms...

  28. [37]

    John Preskill. 2018. Quantum Computing in the NISQ era and beyond. Quantum 2 (aug 2018), 79. https://doi.org/10. 22331/q-2018-08-06-79

  29. [38]

    Smith, Michael J

    Robert S. Smith, Michael J. Curtis, and William J. Zeng. 2016. A Practical Quantum Instruction Set Architecture. (2016). https://doi.org/10.1016/j.jasms.2005.06.011 arXiv:1608.03355

  30. [39]

    Svore, Alan Geller, Matthias Troyer, John Azariah, Christopher Granade, Bettina Heim, Vadym Kliuchnikov, Mariia Mykhailova, Andres Paz, and Martin Roetteler

    Krysta M. Svore, Alan Geller, Matthias Troyer, John Azariah, Christopher Granade, Bettina Heim, Vadym Kliuchnikov, Mariia Mykhailova, Andres Paz, and Martin Roetteler. 2018. Q#: Enabling scalable quantum computing and development with a high-level domain-specific language. (ma...

  31. [40]

    Gambetta

    Kristan Temme, Sergey Bravyi, and Jay M. Gambetta. 2017. Error Mitigation for Short-Depth Quantum Circuits. Phys. Rev. Lett. 119 (Nov 2017), 180509. Issue 18. https://doi.org/10.1103/PhysRevLett.119.180509

  32. [41]

    Tony T Tran, Minh Do, Eleanor G Rieffel, Jeremy Frank, Zhihui Wang, Bryan O‘Gorman, Davide Venturelli, and J Christopher Beck. 2016. A hybrid quantum-classical approach to solving scheduling problems. In Ninth Annual Symposium on Combinatorial Search

  33. [42]

    E. F. Valeev. 2019. Libint: A library for the evaluation of molecular integrals of many-body operators over Gaussian functions. http://libint.valeyev.net/. (2019). version 2.6.0

  34. [43]

    Jianwei Wang, Stefano Paesani, Raffaele Santagati, Sebastian Knauer, Antonio A Gentile, Nathan Wiebe, Maurangelo Petruzzella, Jeremy L O‘Brien, John G Rarity, Anthony Laing, et al. 2017. Experimental quantum Hamiltonian learning. Nature Physics 13, 6 (2017), 551. , Vol. 1, No....

  35. [2015]

    Parallel Comput

    ScaffCC. Parallel Comput. 45, C (June 2015), 2–17. https://doi.org/10.1016/j.parco.2014.12.001

Pith tools

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