Target gateset vs supported gateset

[mpharrigan]

There are two concepts which are currently conflated:

• The set of gates that a device can do
• The set of gates you'd like to compile to

These can be the same, but the second can be a subset of the first. The first should be query-able given a device whereas the second is something the user chooses.

Related: why do I have to choose a gateset when setting up a QuantumEngineSampler? It should tell me what it can do! I suppose there can be two mutually-incompatible supported gatesets but this will likely be rare and doesn't affect the distinction outlined in this issue

[maffoo]

I'm glad you're thinking about this, @mpharrigan. I agree that this is an important distinction, and that there are lots of improvements we can make in this area. I also think that the way we combine the abstract notion of "gateset" with serialization should be fixed.

Internally we have a sampler implementation that knows about all supported gatesets and picks an appropriate gateset on the fly for whatever circuit you ask it to run. This avoids the need to specify a gateset when constructing the sampler, which is nice. Currently the only way to choose is to try to serialize the circuit to each gateset and pick the first one that succeeds (which goes to my point above about conflating gatesets and serialization) but it's definitely an improvement IMO.

[dabacon]

This is an argument that devices should not be responsible for compiling, right? I think this is very similar in nature to the debate over decompose. What you want to compile into is context dependent and there is no often no "optimal" solution (especially because gate combinations that produce the same unitary may have different behaviors with respect to noise).

Do you have suggestions for what we should be doing here?

+1 to @maffoo s comments about the gate set decoupling and also about not having to specify the gate set in sampler.

[alexandrupaler]

The fact that a device is a tuple of (constraints, gate set, etc) can be seen independent of the reality of the device.

There may be multiple devices - virtual and real - and this helps imagine a pipeline of circuit compilation and optimisation. A maybe exaggerated example: RepetitionCodeDevice sitting on top of a IonTrapGeneralDevice that sends its output to a SimulatorDevice which exports Quil.

IMO, the fact that devices are so flexible and expressive in Cirq is one of the strong points.

[tanujkhattar]

Having a list of cirq.CompilationTargetGateset exposed from device.metadata.target_gatesets is the solution now. @verult is working on it's adoption in cirq_google. I think we have all the abstractions in place to make this happen and device specific implementations will be part of migrating individual devices that can support multiple target gatesets.

cc @MichaelBroughton @verult I'm in favour of closing this issue. LMK your thoughts.

[verult]

I'm leaning towards leaving this issue open for now until the abstraction is implemented in cirq_google, so that we can get some user feedback on the final API before marking this as fixed. WDYT?

[dstrain115]

I think we should close this issue. Between the new Devices API and Transformers/cirq.CompilationTargetGateset, I think most of these issues are solved from a conceptually basis. There's not a clear action item besides that in this bug, so I think
we should close this issue now. @mpharrigan Do you agree that this issue can be closed now?

[mpharrigan]

I'd agree with of closing in favor of more targeted issues

• adopt CompilationTargetGateset in cirq_google
• continue(?) to remove gate_set as a cosntructor-like arg for engine samplers

[verult]

Closing this as all tasks above are tracked in #5050.