quil-lang / quil

Specification of Quil: A Practical Quantum Instruction Set Architecture
https://quil-lang.github.io/
Apache License 2.0
104 stars 16 forks source link

Change pauli sum spec to reflect quilc implementation #56

Closed Spin1Half closed 2 years ago

Spin1Half commented 2 years ago

The spec for quil does not match quilc for pauli-sum gates. This PR will make the two consistent (the alternative would be to change quilc's behavior, but I'm expecting this is preferred instead).

The canonical gate example seemed to actually be fine as is, I'm not sure about the electronic structure simulation example though.

ecpeterson commented 2 years ago

My gut reaction is that quilc ought to be changed rather than the spec. Yes, changing quilc's behavior may surprise some people who have been using this feature; on the other hand, quilc having the wrong behavior, understood against theorists' established conventions, will surprise more people.

I think that RX, RY, and RZ match theorists' expectations, and X, Y, and Z in DEFGATE AS PAULI-SUM ought to conform to

DEFGATE RG(t) q AS PAULI-SUM:
    G(k*t) q

for some real constant k which is independent of G. I think theorists like to take k to be 1/2 (or maybe it's -1/2?).[1] I don't think quilc meets this expectation — or, if it does, it's only through goofy interventions.

I recognize that this will be a pretty thankless task from the programmer's perspective: changing these definitions may mean chasing signs through a lot of the quilc source tree, with no new feature won for the effort. I can only offer that both users, maintainers, and contributors would all prefer matching conventions.

[1] - I think they're "wrong" and that k should be 1, but I recognize that this is a minority opinion.

braised-babbage commented 2 years ago

It's funny, I had the opposite reaction, which is to say that I assumed that theorists expectations would be that the Pauli sum represents a Hamiltonian, and the gate is the corresponding time evolution operator. If that is the case, then the -i is what you get from Schrodinger's equation (this sort of breaks down because you're supposed to also get Planck's constant).

Re: your rotation gates, i think the usual thing is RG(t) = exp(-itG/2). Again, that's taking G/2 as the Hamiltonian. The factor of 1/2 is to make the difference in eigenvalues equal to 1 (to normalize the phase accumulation).

I'd prefer the convention that minimizes the risk of user error (I'm still not sure which one does that). From that perspective, the real issue is that the name DEFGATE ... AS PAULI-SUM just doesn't tell you enough.

Spin1Half commented 2 years ago

goofy interventions.

@ecpeterson Could you explain why this referenced line of code is in that function?

It's lead to what feels like strange behavior, for example if I call the function on each pauli term with a 1 prefactor, I get -X Y Z:

Screen Shot 2022-04-18 at 12 01 15 PM

As a consequence, if I want to redefine RX RY RZ in std gates as pauli sums without breaking any tests, I must do it like this (adding the negative to only the RX):

Screen Shot 2022-04-18 at 12 02 16 PM

In line with @kilimanjaro 's thinking, my expectations initially were that the Pauli sum represents a Hamiltonian and thats why quilc is implemented as it is, but I could see i being the prefactor instead of -i as well. However, the inconsistency between X and Y/Z does not make much sense to me, this seems to make neither of those correct.

ecpeterson commented 2 years ago

I can't explain it. Maybe it arose because some identity wasn't working out, or maybe I just thought that X had some minus signs in it. I wish I'd left a comment explaining the reasoning.

No matter what the reasoning was, I can't imagine it was very good, so I encourage you to change the behavior as you see fit.

stylewarning commented 2 years ago

My opinion is to settle on e^(-iH(t)), allow DEFGATE AS HAMILTONIAN, and issue a friendly warning for PAULI-SUM.