rigetti / pyquil

A Python library for quantum programming using Quil.
http://docs.rigetti.com
Apache License 2.0
1.4k stars 341 forks source link

[discussion] Move the borders between QVM and QPU #356

Closed mpharrigan closed 5 years ago

mpharrigan commented 6 years ago

There are typically three stages in quantum programming

  1. Write and debug using wavefunction-based methods
  2. Run the program as if it were running on a real device, perhaps with a noise model
  3. Run the program on a device.

The current distinction between QVMConnection and QPUConnection groups (1,2) and makes (3) separate. This causes some API warts: the difference between the two run_and_measures, and the different behavior on the QVMConnection between run+MEASURE and run_and_measure.

I propose we make (1) separate and group (2,3). The quil paper specifies

The QAM may be implemented either classically or on quantum hardware. A classical implementation is called a Quantum Virtual Machine (QVM). We describe one such implementation in Section V-F. An implementation on quantum hardware is called a Quantum Processing Unit (QPU).

(h/t @tarballs-are-good ) so (2) should be named with the QVM moniker, (3) should continue to be named with the QPU moniker, and (1) should be re-named to not mention a QVM but rather stress the wavefunction simulation aspect.

mpharrigan commented 6 years ago

Example of what this might look like:

program = Program([H(0)])

# (1)
simulator = WavefunctionSimulator()
wfn = simulator.wavefunction(program)
i = np.argmax(wfn.probabilities())
# ...

# (2)
qvm = QAM(device='qvm', noise=0.05)
prog_with_measures = measure_all(program)
bitstrings = qvm.run(prog_with_measures)
qvm_expectation = np.mean(function_that_operates_on_bitstrings(bitstrings))
# ...

# (3)
qpu = QAM(device='acorn')
bitstrings = qpu.run(prog_with_measures)
qpu_expectation = np.mean(function_that_operates_on_bitstrings(bitstrings))
# ...
stevenheidel commented 6 years ago

👍 in favour of this (except for the name QAM, that's rather jargon-y)

/cc thoughts from @willzeng @tarballs-are-good

willzeng commented 6 years ago

@mpharrigan Thanks for the clear presentation. I am in favor this change. It is a clear conceptual improvement.

I propose QAM --> QuantumComputer. While it certainly is a QuantumAbstractMachine in the background that is the unifying concept this sounds like you are targeting a mathematical object rather than a real computer. In fact, I would argue that QAM provides a clean definition for a quantum computer (including the shared memory aspect). Thus QuantumComputer seems simplest.

That said, I almost wish we had called it a Hybrid Quantum Machine rather than a QAM in the Quil paper as this would distinguish the hybrid aspect from what others claim a QC to be. Thoughts @tarballs-are-good ?

(also this naming change should block implementation work, I'm sure we'll come up with the right thing)

cbosborn commented 6 years ago

I'm also enthusiastic for this change. Can we still find a way to make it easy for users to set noise on the qvm by a QPU target? We've gotten a lot of positive feedback on this feature in 1.3.

vtomole commented 6 years ago

@willzeng I think QAM is the appropriate name in the Quil paper because all "robust" quantum computers will have to interface with classical computers. Regarding changing QAM to QuantumComputer, the QVM is a simulation of a quantum computer. If we are talking semantics,

qvm = QuantumComputer(device='qvm', noise=0.05)

is a little misleading. I agree that QAM provides a clean definition for a quantum computer, but the implementation of the QAM (simulation on classical hardware vs simulation on quantum hardware) is where a distinction should be made. I would argue that only the QPU should be called a quantum computer. Let me know what you think.

marcusps commented 6 years ago

Is this just a discussion about naming conventions and constructor function signatures, or can we also debate the different behaviors of run when using QVM vs QPU?

I personally would want a strict behavioral equivalence between the QVM and the QPU, and just struggled with the fact that the QVM wanted MEASURE instructions in order to make the run meaningful, which was quite frustrating (and not well documented).

@mpharrigan @tarballs-are-good

mpharrigan commented 6 years ago

The latter 👍

mpharrigan commented 5 years ago

there's some additional "realism" features like erroring on bad topology or gateset, but this is largely done with the new QuantumComputer object