Update non-gate quantum ops to have gates

[daxfohl]

Describe your design idea/issue

It would be nice to make things consistent such that quantum operations (as opposed to control operation classes like subcircuits and feedforward) all have associated gates. Most do. The ones I see that don't are:

• BooleanHamiltonean: This seems straightforward to convert: instead of qubit_map, the BooleanHamiltoneanGate.init would just take a list of names, and then implement the decompose_once_with_qubits protocol to create the qubit_map on demand using self.names and the passed in qubits.
• PauliStringPhasor and PauliStringGateOperation: Haven't looked at these.
• GlobalPhaseOperation: This is always an oddball. But we could make a GlobalPhaseGate easily enough and it would fit better in some ways. Granted, GlobalPhaseGate().on(tuple()) is weird. But it does play well with other gates, like if someone wanted a function that zipped up gates and qubits, this would allow them to add global phases to that.

The advantages of doing this are:

• Gates are more reusable (you can have my_x=X**0.8 and then apply that to different qubits, etc. With an op you'd have to **0.8 each time). With things like BooleanHamiltonean this could be nice too.
• They fit cleaner in gatesets (GlobalPhaseGate would likely allow for cleanup of some existing gateset code)
• You can typically operate on them at a lower level, e.g. with state vectors and axes, rather than requiring qubits and full simulators.
• Consistency for consistency's sake.

Disadvantages:

• e.g. GateOperation(PauliStringPhasorGate(), q) is not the same as PauliStringPhasorGate.on(q): we still want the latter to return a PauliStringPhasorOperation because it has extra functionality. So maybe this is confusing.

[tanujkhattar]

There's also ArithmeticOperation; QuirkInputRotationOperation.

[tanujkhattar]

Regarding the disadvantage mentioned:

There are many operations which are not gate operations but have a .gate property. The confusing case that you mentioned would be applicable to all those cases. Eg: controlled_gate.on(*q) is not same as GateOperation(controlled_gate, q). Another prominent example is PauliString (operation) vs DensePauliGate (corresponding gate)

[tanujkhattar]

Gates are more reusable (you can have my_x=X**0.8 and then apply that to different qubits, etc. With an op you'd have to **0.8 each time). With things like BooleanHamiltonean this could be nice too.

With ops you can do ops.with_qubits() to apply them to different qubits.

[95-martin-orion]

Related: #1561

[daxfohl]

@tanujkhattar: It looks like ArithmeticOperation will be possible to make into a gate. I don't think QuirkInputRotationOperation will be possible though, since it wraps another Operation. To make a gate, we'd have to redesign the thing so that it wraps a Gate instead, which, IDK if that fits with what QuirkInputRotationOperation is supposed to do. If so, then probably it's possible to change that to a gate too, but IDK if the ROI is there.

[daxfohl]

@tanujkhattar Looking again, I believe the QuirkInputRotationOperation would be a valid candidate. It can wrap a gate instead of an operation. Of course, that means it's limited to wrapping gates, but the point of this project is to push as many things down to the gate level as it makes sense to do. So, it won't be able to wrap a CircuitOperation or a ClassicallyControlledOperation. Which makes sense, and is probably better.

[tanujkhattar]

This would be useful towards the Cirq 1.0 roadmap item for organizing gate relationships.

xref #3242

[daxfohl]

@tanujkhattar can you add the pre-1.0 tag to this one? #4705 and #4702 are still pending review.

[vtomole]

I've added it.