Quantum information science primitives

[balopat]

Feature: Quantum information science primitives

Problem: Cirq recently moved to break out quantum information science primitives, like entropies, basic state operations (partial trace), and more into a separate subdirectory, qis. This feature would be to complete out the O(20) or so methods that are generally useful for this package. These typically do not work with quantum computer data, but instead with state vectors, density matrices, or Kraus operators (though these may be constructed via tomography)

Rough requirements:

• Distance measures for quantum state vectors and density matrices
• Entropy measures
• Distance measures for gates and channels
• Wigner functions
• Choi matrices
• Roughly the set of tools necessary to implement problems in Nielsen and Chuang
• Beyond Nielsen and Chuang tools
  • the diamond norm
  • simple separability criteria

[daxfohl]

@balopat do you want to break out separate tasks for some of these? As is, it's kind of too abstract to get started on anything specific. I think we could make good progress doing chunks at a time. Some of them could be be good first issues / good for learning.

[balopat]

I agree @daxfohl that this would be fantastic set of starter issues.

[daxfohl]

While investigating #3248 a thing that seems missing from Cirq is an abstractions around these qis primitives. We go straight from circuit elements to plain old ndarrays. I think it would be good to have a middle layer of classes that represent these primitives, and have the functions all based on these rather than on ndarrays. This will provide a lot more structure when working with these types. It also allows for hierarchies and abstractions that do perf optimize under the hood.

The question is how do we get there from here? Currently Cirq protocols all return the raw data. Can we change that? It would be breaking, presumably, unless there's some python magic that makes it compatible.

[balopat]

QIS primitives should work on matrices - that is their definition. I would not move away from that. What is your suggestion a bit more concretely and what problem are you trying to solve with more structure?

1.) I could see helper methods to be potentially useful that take a QuantumStateLike object or a simulator ActOnArgs state, or a PauliString operator, or Operation class and convert them to the necessary matrix representation and applies them. The conversion would be leveraging unitary, channel and mixture protocols. 2.) did you mean adding an extra layer of abstraction like "HermitianMatrix", "NormalMatrix", "UnitaryMatrix", etc? I'm not sure that's too useful...

[daxfohl]

IDK if this page has changed since @vtomole originally linked it here https://github.com/quantumlib/Cirq/issues/2763#issuecomment-597314438. He mentioned ~10 procedures, but it now contains a series of full class hierarchies. https://qiskit.org/documentation/apidoc/quantum_info.html

That kind of structure is what I had in mind as I was initially thinking about this issue. I think that's a good way to represent things. Like Kraus, Choi, SuperOp, etc all extend Channel. When working with these objects, you get nice autocomplete, you get a layer of abstraction (e.g. you can write a function that accepts Channel and it will work for any representation, etc), you get better type safety than when working with raw ndarrays.

Regardless, the functions that do the linear algebra need to be there either way. So I'll work on drafting that RFC up.

[mpharrigan]

xref the discussion on https://github.com/quantumlib/Cirq/issues/2904

[mpharrigan]

Can you explain why you closed this? AFAIK, most of the bullet points in the original post have not been implemented and are still relevant

[vcatherine]

@MichaelBroughton to comment (these issues were closed in a live meeting with Michael and Tanuj just now)

[mpharrigan]

In the spirit of openness, best effort should be made to transcribe offline discussions into the issues where relevant