Add super_to_choi and choi_to_super

[akirakyle]

Unlike qutip, which uses type = super, superrep = choi to mark a qobj as a superoperator in the choi representation, I personally think it makes more sense to just reuse the normal Operator type to represent a choi matrix since it must be a valid density operator after all. Also it often makes sense to compute things like the Von Neumann entropy of the choi state. To convert back to the superoperator representation, one needs to assume some convention for which of the two Hilbert spaces is the auxiliary/reference/environment system and which represents the channel's output system. I've chosen the convention which seems standard to have the first system be the reference and the second be the output system.

I still need to add docs and tests but I thought I'd open this now as a draft so that there can be some discussion of these choices. Also this might be a good time to follow through on the TODO to upstream _permutedims and maybe figure out how to make it operate on ReshapedSparseArray?

Rough TODO list:

• [x] another type for the Kraus representation
• [x] converters back and forth between the 3 types
• [ ] docstrings with doctest-based examples
• [ ] test for correctness
• [ ] application methods (e.g. at the very least having multiplication operator between superoperators and density matrices)

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 96.29630% with 1 line in your changes missing coverage. Please review.

Project coverage is 92.17%. Comparing base (bb71f52) to head (a3ed53c). Report is 16 commits behind head on master.

Files with missing lines	Patch %	Lines
src/superoperators.jl	96.29%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #115      +/-   ##
==========================================
- Coverage   93.00%   92.17%   -0.84%     
==========================================
  Files          25       26       +1     
  Lines        3104     3258     +154     
==========================================
+ Hits         2887     3003     +116     
- Misses        217      255      +38     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Krastanov]

@akirakyle , I think here it would be a great place to use the multimethod style of julia.

With the current setup you are proposing, the following will be a bit difficult: applying the choi superoperator to some operator.

My initial suggestion would be to create

struct ChoiSuperOperator{T} <: AbstractSuperOperator
    choistate::{T}
end

ChoiSuperOperator(sop::SuperOperator) = ChoiSuperOperator(_super_to_choi(sop))
SuperOperator(csop::ChoiSuperOperator) = ...

Then you can easily have the same function (e.g. multiplication or apply!) have different methods for Operator and ChoiSuperOperator. I imagine this would avoid confusion down the line where you would want the same function to act on an Operator that just represents some state or some unitary and an Operator that would have meant to represent a Choi state in a superoperator.

Do not hesitate to voice dissent if this seems misguided. Let me know what you think.

[akirakyle]

@Krastanov I think it might make sense to keep this in draft status for awhile while I get some experience using the choi representation in my own code to see what feels most natural. I think you might be right in that the safest method would to introduce a ChoiSuperOperator subtype of AbstractSuperOperator and explicitly method dispatch the functions you want to think of it as a state appropriately (such as entanglement_entropy).

[akirakyle]

@Krastanov I am finally getting back to working on this and I noticed that the PauliTransferMatrix and ChiMatrix types don't subtype AbstractSuperOperator. Should they? After all they just different representations of superoperators and I think I will be modeling the ChoiState type on them.

I will be needing the Kraus representation of superoperators as well so I think I will go ahead and implement a KrausOperators type that will behave similarly to all the other explicit superoperator representations. Also as I'm working on this would it make sense to put some documentation of more of the high level concepts into the superoperators page here? I'm thinking something along the lines of this doc page from forest benchmarking, which I've found to be a very useful reference whenever I've been working with superoperators.

[akirakyle]

I'm also noticing that the constructors for SuperOperator, DensePauliTransferMatrix, and DenseChiMatrix are all essentially the same so perhaps we should just rely on the constructor for SuperOperator and maybe introduce a DataSuperOperator type to parallel the way construction of dense and sparse Operator is handled?

[Krastanov]

Hi, Akira! Pardon the slow response, I did not notice that was converted away from draft status. I will try to review this in the next few days.

[Krastanov]

Hi, Akira! I guess a week turned into a month, sorry about that.

I did some very minor touchup, but feel free to disregard the last commit (by doing a force push here). Otherwise, do not forget to do a pull first to incorporate it.

Given other things you have mentioned in this thread, does the following todo list sound reasonable as prerequisite for merging (of course, there is no expectation that you have to do this -- it is already appreciated that you have donated some of your time to start this):

• [ ] another type for the Kraus representation
• [ ] converters back and forth between the 3 types
• [ ] docstrings with doctest-based examples
• [ ] test for correctness
• [ ] application methods (e.g. at the very least having multiplication operator between superoperators and density matrices)

I will add this to the PR description and convert it to a draft for now (that helps me with organizing my own PR-review work). Do not hesitate to convert this back to non-draft and request a review.

[akirakyle]

That looks like a solid todo list to me and represents what I would like to see with regards to getting all the common superoperator representations implemented with a reasonable interface.

I've been consumed by another research project which is why I haven't been spending time on this lately but I do intended to come back to this at some point, hopefully soon.

[akirakyle]

@Krastanov I've finally been coming back to this PR as I've picked up the research project that relies on it again!

I've implemented the KrausOperators representation and converters to/from SuperOperator and ChoiState. I still need to think about how to incorporate PauliTransferMatrix and DenseChiMatrix as they are also types of super operators but only valid for tensors of qubit or qudit basis afaiu. In fact, I think the way QO has chosen to represent density operators as a specific type of quantum operator with equal basis_l and basis_r means that the SuperOperator type can represent types of quantum maps that don't admit a Kraus decomposition. There's currently a comment about this in the docstring for theKrausOperators struct the latest update to this PR.

The conversion from ChoiState to KrausOperators requires finding eigenvalues and vectors. Currently I'm just using LinearAlgebra's eigen, but it would be useful if sparse matrices were handled without the conversion to dense, which I think would require pulling in something like Arpack.jl or ArnoldiMethod.j. Furthermore, there's the associated numerical tolerances and the interface for setting those which I have a rough implementation of currently.

PS: I am currently in Boston until this Sunday, then stonehill until next friday, so if you are around and would like to meet up in person to discuss this or anything else julia/quantum related, let me know when works!

[akirakyle]

@Krastanov I think this should finally be ready for review!

I've split off implementing Kraus operators into a separate PR #177 to make it easier for both myself and for review.

[Krastanov]

Thanks! I will try to look into it later this week. Please ping me if I have not done so by next week