QVM <-> pyQuil Pain Points

This is a general list of issues that can be broken out into smaller issues, but I wanted to get them down.

Props to @ecpeterson for writing these. I’m just the messenger. In general, these center around how easy (or not easy) it is to use the QVM with pyQuil.

1. QVM in density matrix mode returns density matrices when ‘wavefunction’ is requested. Should have a separate name in pyQuil, should check a different set of normalization conditions.
2. QVM in density matrix mode offers possibility to return probability distribution. Is this call available in pyQuil? It requires different bit unpacking.
3. QVM in stateful mode offers ‘apply for effect’. Expose this in pyQuil.
4. Can bit unpacking be treated uniformly? Robert does ctypes casting and Erik does numpy buffers and pyQuil does struct.unpack.
5. Where does this density matrix stuff sit relative to the QVM <: QAM vs WavefunctionSimulator split? There’s also a ReferenceDensitySimulator that doesn’t belong to this hierarchy.
6. The Pauli heatmaps from process tomography is useful. Eric wrote some matplotlib code to generate them; he’d like to polish this for inclusion.
7. How does one take the results of the forest.benchmarking process tomography code and extract from it data suitable for feeding into a tomograph plotter? Like there are standard methods for generating the data, but it would be nice to also have a standard munger to get it into the right form.
8. Eric would like to include the “cheater’s process tomography” code that he wrote for use against the density matrix QVM.
9. Polish and publish Erik’s shared memory mode starter notebook, which is very useful.
10. Legal density matrices obey a bunch of properties (e.g., Hermitian). Make it easier to edit density matrix shared memory w/o exiting this subspace. Eric wrote something to extract a representation as a PauliSum, which was already useful for me.
11. Expose density matrix QVM in batch mode.
12. Eric’s first attempt at generating these tomographs was to couple the forest.benchmarking code to my local QVM, and this was very slow: 5-10m for a 1% inaccurate picture of a 2Q operator. He thinks the bulk of the slowdown was in the communications layer; it would be worth profiling this and improving these repeated-call scenarios.

[ecpeterson]

Some notes from @joshcombes about connections with forest.benchmarking:

Point 6: There are some visualization routines implemented at https://github.com/rigetti/forest-benchmarking/blob/master/forest/benchmarking/plotting/ . Could be that other visualization routines belong here too.

Point 7: There are some things along these lines: https://github.com/rigetti/forest-benchmarking/blob/superoperator-cleanup/forest/benchmarking/superoperator_conversion.py .

Point 10: Also some related things: https://github.com/rigetti/forest-benchmarking/blob/master/forest/benchmarking/random_operators.py . It would be nice if whatever was envisioned for 10 at least made contact with this.

Point 12: have u considered PyQVM

[stevenheidel]

There are still advantages to this (as evidenced by internal usage):

• amortizing the cost of serialization and sending over the wire, keep in mind there’s still a two-way communication that needs to happen between each one which is insignificant compared to the program time but still significant when added together
• doing other work in parallel with relative ease

For example in Python you can do something like this:

results = send_jobs_to_qpu_and_get_iterator_back(jobs)

for result in results:
     # local processing and execution will both be happening here
     process_result(result)