Feature: "DEFEXPI"

[ecpeterson]

Back at it again.

This PR adds support for:

• A new gate definition class, DEFGATE ... AS PAULI-SUM, which defines a (possibly parametric) gate as an exponentiated Pauli sum (with possibly parametrically-determined coefficients). For example, the following gives a gate definition for CPHASE:

DEFGATE CPHASE(%alpha) p q AS PAULI-SUM:
    ZZ(-%alpha/4) p q
    Z(%alpha/4) p
    Z(%alpha/4) q

• Parametric compilation routines for Pauli sum gate definitions which are linear in a single gate parameter.

Some possible follow-ons:

• Benchmark this against the Tweedledum diagonal compiler.
• Investigate the diagonal expansion strategy. Can it be made usefully topology-sensitive?
• Write some tests.

Attendant PRs:

• propose DEFGATE ... AS PAULI-SUM for inclusion quil#38
• Add support for DEFGATE ... AS PAULI-SUM rigetti/pyquil#1125

Closes #422. Closes #423.

[notmgsk]

First pass. I will admit I barely glanced at the parsing code, since it is the least interesting and probably the buggiest part. 😬

[jmbr]

Quick review for the moment. Things are looking good! I miss having some unit tests.

[notmgsk]

Um pequeno erro:

(quil:parse-quil "DEFGATE CPHASE(%alpha) p q AS PAULI-SUM:
    ZZ(-%alpha) p q
    Z(%alpha) p
    Z(%alpha) q

")

[jmbr]

Below are some more suggestions that occurred to me while studying the code.

The fact that compilation and, specifically, gate depth is non-deterministic surprises me. For example,

QUIL> (dotimes (i 10) (print (length (parsed-program-executable-code (quilc::process-program (parse-quil "
DEFGATE HAMILTONIAN(%theta) q0 q1 q2 q3 AS PAULI-SUM:
    ZZIZ(%theta) q0 q1 q2 q3

HAMILTONIAN(pi/4) 0 1 2 3") (quilc::lookup-isa-descriptor-for-name "8Q"))))))

59 
55 
58 
58 
62 
56 
59 
61 
57 
55 
nil

produces different gate depths (the number of 2-qubit gates seems to be constant, though). Is this an artifact of qs-compiler?

[jmbr]

@jmbr: I'm not sure what's going on with these inflated CZ counts, but it's not in this area of the code:
I'll investigate tomorrow. When I turn *compiler-noise-stream* on, I see that recognize-UCR gets called on the invocation of HAMILTONIAN, which results in a thrice FORKED RZ, which just compiles worse. After demoting RECOGNIZE-UCR further down the global compilers list, this problem goes away.

Thanks for the heads up. That's spooky indeed.

By the way, just the other day I saw a link to a directly relevant compiler debugging technique: http://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/

[ecpeterson]

This is a neat suggestion. We'd have to track down and eliminate the nondeterminism to make it work for us. That's not an unreasonable task, but one would have to think very carefully about the problem we solved in the addresser by injecting randomization.

[stylewarning]

When I turn *compiler-noise-stream* on, I see that recognize-UCR gets called on the invocation of HAMILTONIAN, which results in a thrice FORKED RZ, which just compiles worse. After demoting RECOGNIZE-UCR further down the global compilers list, this problem goes away.

Can we document this in the global list as an artifact for future visitors?

[stylewarning]

Overall looking good. I'd like to go through the motions of making sure the addition is (1) in the quil spec and (2) doesn't choke the QVM.

[stylewarning]

@_@

[ecpeterson]

I agree, and I'd take suggestions as to how to name these two cases so that the functions can be split apart. The two use cases are:

(anon-gate "DUMMY-NAME" matrix qn ... q0)
(anon-gate parametric-gate-defn parameter-list qn ... q0)

[stylewarning]

are we avoiding the bad boi that is magicl.transcendental

[ecpeterson]

I suppose we are. We are calling out to MAGICL, which calls out to LAPACK, but for the diagonalization routines instead of the exponentiation routines.

Importing MAGICL.TRANSCENDENTAL requires the somewhat uncomfortable secondary import of expokit, which we've so far avoided actually using (and which this also wouldn't use).

[appleby]

tests would be good but I see that is under the "follow ons" section of the PR description

[ecpeterson]

Added a test, which also fixed a bug introduced during PR review.

[braised-babbage]

It's difficult to really verify the details on much of this (e.g. whether the compilation routines are correct, and so on), so one must rely on tests. In that regard, I think testing the output of make-matrix-from-quil before and after compiler-hook on exponentials of random Pauli terms is a nice idea, and gives some confidence. However, for legibility/hackability I would strongly prefer for a few additional tests which are more explicit and which exercise narrower code paths. In particular,

• pauli-term->matrix seems to basically be doing the equivalent of reducing Pauli factors via magicl:kron, so a test could check that pauli-term->matrix is in fact equivalent to something simpler but perhaps slower
• parametric-pauli-compiler could have a few explicit sanity checks. For example, exp(-iZt/2) should be equivalent to RZ(t), and so on (might consider doing one for a Pauli term of degree 2 as well).
• I'm not totally clear on what parametric-diagonal-compiler does but it could probably also be tested explicitly in some simple cases.

[jmbr]

It's difficult to really verify the details on much of this (e.g. whether the compilation routines are correct, and so on), so one must rely on tests. In that regard, I think testing the output of make-matrix-from-quil before and after compiler-hook on exponentials of random Pauli terms is a nice idea, and gives some confidence. However, for legibility/hackability I would strongly prefer for a few additional tests which are more explicit and which exercise narrower code paths. In particular,

I concur. The exp-pauli function (and its corresponding unit test) could provide a baseline for comparison.

[stylewarning]

@ecpeterson please make sure any follow ons are filed as issues