Closed mpharrigan closed 5 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))
# ...
👍 in favour of this (except for the name QAM, that's rather jargon-y)
/cc thoughts from @willzeng @tarballs-are-good
@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)
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.
@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.
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
The latter 👍
there's some additional "realism" features like erroring on bad topology or gateset, but this is largely done with the new QuantumComputer
object
There are typically three stages in quantum programming
The current distinction between
QVMConnection
andQPUConnection
groups (1,2) and makes (3) separate. This causes some API warts: the difference between the tworun_and_measure
s, and the different behavior on theQVMConnection
betweenrun
+MEASURE
andrun_and_measure
.I propose we make (1) separate and group (2,3). The quil paper specifies
(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.