Circuit superoperator #4550
Circuit superoperator #4550
Conversation
There was a problem hiding this comment.
This is cool but it seems to contain a lot of logic hidden in these nested functions that may be useful to others
- `operations_to_kraus(ops, all_qubits)
all_operations_dense(moment, all_qubits)get_moment_superoperator(moment, all_qubits)as discussed
Did you consider using the "other" einsum api that uses integer indices instead of string names for the tensor legs?
|
Extracted the nested functions and made them methods in Considered the other einsum API, but it leads to more complicated code since it expects the index lists to be interspersed between arrays. PTAL @mpharrigan @tanujkhattar |
cirq-core/cirq/ops/moment.py
Outdated
| return Moment(*operations) | ||
|
|
||
| def _kraus_(self) -> Sequence[np.ndarray]: | ||
| """Returns Kraus representation of self.""" |
There was a problem hiding this comment.
Can you add some more details to the docstring? For example, a mention that the method performs parallel concatenation of kraus operators of the individual operations ?
Also, do you think it would be useful to have methods in cirq/qis/channels for serial and parallel concatenation of mixtures and kraus operators, which can be useful general primitives?
The parallel concatenation method can be used here and the serial concatenation method can be used in the kraus/mixture protocol methods while computing operators of an operation using the operators of it's decomposed operations.
There was a problem hiding this comment.
Re docstring: Done.
Re composition: Composing Kraus representations (in series or in parallel) is cumbersome because it results in a representation with a very large number of Kraus operators. We should avoid it whenever possible. For serial composition we can always(*) avoid it by using superoperator representation instead. For parallel composition all our channel representations are cumbersome (e.g. superoperator becomes a very large matrix). However, we can still describe channels using circuits which avoids the issue. Thus, we should not need to compute serial composition of Kraus representations (else we're doing it wrong) and we should only compute parallel composition in the context of a circuit moment. For this reason, I'd rather we don't implement serial composition of Kraus representations at all and keep the code for parallel composition in Moment._kraus_.
(*) It's interesting how parallel (or causally independent) composition preserves all the details of the composed processes preventing us from compressing it while serial (or causally connected) composition loses some information about what's going on enabling a compressed description. This observation has inspired a lot of cool ideas.
There was a problem hiding this comment.
Makes sense, thanks for the explanation!
I missed them in quantumlib#4550.
I missed them in quantumlib#4550.
Compatible with the protocol defined in #4545.
Follow-up:
cirq.superoperator_to_krauswhich will enable the computation of Kraus representation of small noisy circuits.