Generalize MatrixGate to channels

[dkafri]

Is your feature request related to a use case or problem? Please describe.
I want to be able to algorithmically define arbitrary channel operations (e.g. with Kraus operators) without having to define my own custom Gate or Operation class.

Describe the solution you'd like
Basically something equivalent to MatrixGate, but which takes a tuple of Kraus operators instead of a single unitary.

[optional] Describe alternatives/workarounds you've considered
Creating a custom subclass that does the same thing (what I'm doing now).
Generalizing MatrixGate to allow for Kraus operators

[optional] Additional context (e.g. screenshots)
This is useful in the context of noise modeling when you have qubit-specific noise models corresponding to different numerical parameters.

What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I'm not really blocked by it, it is an idea I'd like to discuss / suggestion based on principle

[balopat]

Discussed on Cirq Cynq: this sounds reasonable, and we could also even add this functionality for mixtures too.

[artvandalay404]

I can tackle this if it is needed. Thanks!

[balopat]

Thank you for volunteering - go for it @satw1knandala!

[artvandalay404]

Question about this @balopat @dkafri - can this be achieved by creating a class that just creates several matrix gates by looping through the tuple of kraus operators? something like a wrapper that manages all the different matrix gates at once? let me know if there might be a more cirq style architecture for this. thanks!

[dkafri]

I am not a Cirq expert, but I think the simplest thing would be to subclass cirq.Gate. The custom class can be initialized with the Kraus operator matrices, which can then be returned for the call to _channel_(). Additionally, for the implementation of on you will want to check that the matrix dimensions match the qubit dimensions.

[dabacon]

@satw1knandala I think you don't want to mix matrix gates and these channel matrix gates. The reason is that matrix gates should be unitary gates, and there is a sort of expectation that it describes such an object. The matrices in the Krauss operators are not necessarily (usually) unitary, so this would likely lead to confusion. I think just passing a tuple of the matrices makes sense here and not delegation.

[verult]

cc @MichaelBroughton @tanujkhattar

[dstrain115]

Why does this need to be done before Cirq 1.0? It looks like it is new functionality that is low priority. I don't see any backwards breaking functionality here unless I am missing something. @MichaelBroughton

[verult]

Ack, I wasn't sure whether it's confirmed that it will be separate from MatrixGate at first, but reading the issue again it does seem like the recommendation leans towards implementing it separately. Moving to after 1.0 but @MichaelBroughton lmk if you think otherwise.

[dabacon]

This exists and is called KraussChannel. Introduced in #4194