Implement GlobalPhaseGate

[daxfohl]

Implements GlobalPhaseOperation in terms of a GateOperation on a new class GlobalPhaseGate.

Mostly involved moving existing functions from the operation to the gate, and then having the operation call those methods under the hood.

xref #4683

@tanujkhattar

[tanujkhattar]

1. Should we deprecate GlobalPhaseOperation in favour of GlobalPhaseGate? I don't think we need to keep both.

2. I'd like to see what other maintainers think about the paradigm shift here -- i.e. we are introducing the first gate in Cirq which should be applied to an empty set of qubits (i.e. op = GlobalPhaseGate(1j).on()).

cc @dstrain115 @MichaelBroughton Thoughts?

[tanujkhattar]

It came up during discussion on Cirq sync that GlobalPhaseGate should act on all qubits instead of acting on no qubits. This is important because now we can have a Controlled CircuitOperation; where the underlying circuit has a global phase. Since we wrap the circuit in a CircuitOperation and apply controls on it, the phase is not global anymore (and hence can influence the output of the circuit). A GlobalPhaseGate acting on all qubits of the circuit can capture this global -> local conversion.

[daxfohl]

That seems like a different kind of gate though, like a TargetedPhaseShiftGate, right? GlobalPhaseGate with no qubits is designed to be a drop-in replacement for GlobalPhaseOp. If we start saying GlobalPhaseGate has different behaviors than GlobalPhaseOp depending on what qubits you provide, then the migration path is much rougher (or impossible in cases where you don't know your qubits in advance).

[tanujkhattar]

That seems like a different kind of gate though

That's right. The comment was that we should probably work directly towards deprecating GlobalPhaseOp in favour of the new gate which acts on all qubits instead of first deprecating GlobalPhaseOp in favour of the drop-in replacement (i.e. GlobalPhaseGate as implemented now) and then deprecating it again in favour of the TargetedPhaseShiftGate (or whatever we might end up calling the new gate).

[daxfohl]

Would we need to deprecate one over the other though? Would we not keep both? Or was the idea of a GlobalPhaseOp just unsound from the start?

If we do need to replace it with something else, what does that new thing do with the qubits it is given? I'm not seeing how those qubits affect the unitary or are otherwise used.

[tanujkhattar]

The original concern I had in mind was that things might not behave as expected if we have a CircuitOperation with a global phase and we control it with other qubits, thus turning the global phase into a relative phase which can impact the output of the final circuit.

However, on digging a bit more, it seems like this particular use case works as expected right now because controlled CircuitOperations decompose into controlled versions of the underlying operations in the circuit and a controlled global phase op behaves like a z rotation, which is expected.

We should still add a custom controlled_by override to GlobalPhaseOperation and return a ZPowGate to make it more clear (similar to how Z.controlled_by returns a CZ).

cc @95-martin-orion Since you originally brought this up in the cirq sync -- do you see any other case where the combination of GlobalPhaseOperation + CircuitOperation isn't behaving as expected?

[95-martin-orion]

cc @95-martin-orion Since you originally brought this up in the cirq sync -- do you see any other case where the combination of GlobalPhaseOperation + CircuitOperation isn't behaving as expected?

You hit the main case I was concerned about, that being the different meanings of "global" when nesting circuits.

[daxfohl]

So what I'm hearing is that since the existing behavior of GlobalPhaseOp is "local" as desired when placed in a controlled subcircuit, we can give GlobalPhaseGate the exact same implementation, meaning there is no need to have it accept qubits in the constructor because they would have no effect and would just be confusing. Is that a correct interpretation?

Should the name be changed to "PhaseShiftGate", so as not to imply a truly global behavior?

[tanujkhattar]

as desired when placed in a controlled subcircuit, we can give GlobalPhaseGate the exact same implementation

Yes, that's right. I'd prefer to stick with GlobalPhaseGate since it's much more descriptive in the common case of adding a global phase to the circuit which shouldn't impact the output. (controlled sub circuits is a special case, and in this case the GlobalPhaseGate would automatically change to a ZPow/controlled gate).

[daxfohl]

That made this PR go from medium to 32 files :) but most of the changes were mechanical. Change GlobalPhaseOp() -> global_phase_op(), and isinstance(x.untagged, GlobalPhaseOp) -> isinstance(x.gate, GlobalPhaseGate).

[tanujkhattar]

Looks good overall. Left a round of comments, mainly around using GlobalPhaseGate in Gateset.

[tanujkhattar]

LGTM