Allow custom gate serialization

[zaqqwerty]

Currently we hardcode the set of serializable gates in a global variable here. It will be useful to various teams to allow the user to set this serializer to correspond with custom backends.

[MichaelBroughton]

This could wind up being a fairly large feature to undertake for adding into TFQ everywhere. I think roughly what would need to be done is:

1. Get support for custom gates of arbitrary size in OSS qsim.
2. Add support for gates of arbitrary size in TFQ (All we need to do here is add a rule for cirq.MatrixGate in the serializer that you linked)
3. Wire up support inside of our C++ ops.

That should be it.

[zaqqwerty]

the main point is to add support for gates that qsim does not support, but that a custom sim passed in as backend might

[zaqqwerty]

I'm thinking of a global getter-setter framework like the low-latency stuff. There would be a default serializer compatible with qsim, but the user could set the global serializer to be any valid cirq.google.SerializableGateSet; there would then be some additional logic forbidding use of custom serializers with None backend

[MichaelBroughton]

Intersting, right now we support a lot (but not all) of the gates one could make in Cirq. Exceptions include: multi qubit control, PhasedXZ and cirq.MatrixGate. This support is provided with a cirq.google.SerializableGateSet. In the past it has been fairly easy to add gates to TFQ and I don't think adding support for any of these gates should really be that much more difficult. We would be blocked on adding cirq.MatrixGate and cirq.Controlled*** gates by the fact that qsim does not support multi qubit matrix gates currently. However, once that has been added (it is on their to do list: https://github.com/quantumlib/qsim/issues/163) there would be nothing blocking us from adding any kind of gate we like to our serializer and the rest of TFQ. I think the way we do serialization is fairly core to the library and can still provide the functionality we are after in more exotic gates without having to worry about "swapping out the serializers". I think we just need to wait for updates to qsim.

One could also argue that it would be nice to swap serializers to accommodate various QPU backends, but I believe once we get comprehensive support for ALL possible cirq gates in TFQ this will become a non-issue for us. Any errors from serialization pertaining to a particular backend would happen from user negligence when choosing that backend. The user would still have to think about the various types of supported gatesets when creating a layer or op with a specific backend. In cirq you can see that in order to hook into an engine sampler you must choose a gateset at instantiation time: https://cirq.readthedocs.io/en/stable/generated/cirq.google.QuantumEngineSampler.html to me this seems like a pretty natural way to do things, because the user no longer has to worry about how TFQ serializes at all (in the default case, and only if they choose more advanced use cases) which makes their life easier.

[matibilkis]

hello! I wonder if there's been any update on this issue; I'm currently trying to feed a circuit with cirq.MatrixGate gates into a TFQ model and running into troubles. Thanks a lot!

[matibilkis]

Hi, just wondering again. I would like to implement unitary compilation with TFQ, but not sure if I can do that in the traditional way (generate the Choi state and calculate Tr(U^\dagger V(\theta)). I wonder if there's any workaround on loading a generic U into the circuit as a MatrixGate.

Is there any way I could help in implementing this serialization of custom Gates ? Thanks!