[DISCUSS] Get rid of xmon gates by merging them into the basic gate set

[Strilanc]

It has become increasingly clear that having the xmon gate set is just duplicating work and creating incompatibility errors for no benefit. I suggest that we merge or move all xmon gates down to the base level.

Here's the proposed plan:

• The to_proto methods of the xmon gates are moved into a single utitlity method
• cirq.google.ExpZGate merges into cirq.RotZGate
• cirq.google.Exp11Gate merges into cirq.Rot11Gate
• cirq.google.XmonMeasurementGate merges into cirq.MeasurementGate
• cirq.google.ExpWGate becomes "cirq.PhasedRotXGate" or similar
• In the engine, we replace the W gate with "generic single qubit gate", because we can do any operation as W(a)^b Z^c and Z is free. We accept any and all operations with a single qubit as long as they have a matrix. The RotZGate will still be special, but only because it's free.

Benefits:

• Less duplication between gates.
• Several xmon-specific optimizers and decompositions can be applied more generally and move out of the google namespace.

Downsides:

• This will break pretty much everyone who has touched XmonGate.
• ExpZGate differs from RotZGate in terms of global phase. Opening that bike shed again.

What do people think?

[dabacon]

Not immediately opposed, but I think we need to figure out the gate set story first. I don't like putting these gates into common core Cirq a priory since they are very specialized to Google hardware. Right now the gates are kind of adhoc and we need to figure out what goes where.

Here is a quick proposal that I haven't thought threw:

• A gate set a collection of gates.
• There is a gate set associated with most of what we have in "common_gates".
• Circuits always need to written in one gate set?
• You can easily define a subset of a gate set to be a gate set. If we have an expressive enough set of common_gates this would mean that many hardware could just define "our gate set is this".
• Gate sets can support each other, i.e. there can be default decompositions between the gates in the gate set. More generally people will want to write optimizers that transform the gate set of a circuit and perform optimal gate decompositions.

I also think we need to think through the naming of the gates a bit more. I think the Rot gates for single qubit are fine, but the Rot11 and two qubit SU(4) elements show some significant bias towards the xmon gate set. Two qubit gates are probably best thought of as exp of a two qubit Hamiltonian.

I definitely would be happy if we got rid of to_proto it feels like an over reliance on inheritance to me.

[babbush]

@dabacon I mostly agree with these suggestions but I am concerned about the particular suggestion that circuits always need to be written in one gate set. The reason I don't like that is because then you'd need to incorporate every gate you introduce into a particular gate set in order to use it in a circuit. Or maybe I misunderstand something.

[Strilanc]

I think we should be a bit more flexible about allowing people to stray outside their gate set in a limited way. This is why, for example, Device now has a decomposition method and this method is called as you add operations in the circuit. It allows people to use Hadamard gates even if they're technically not in the final gate set, and then you do an optimization pass specific to the device to clean up the resulting chaff.

[kevinsung]

I agree. I don't find any of the downsides @Strilanc listed to be compelling.

[dabacon]

XmonGates no longer exist.