Issue: shape of output of `choi_to_kraus`

[dfacoet]

The output of choi_to_kraus should be reshaped, as it does not match the type hint List[List[np.ndarray]].

Currently, choi_to_kraus outputs a (flat) list of Kraus operators. The docs agree with this, but this is in contrast with how Kraus operators are handled throughout the package, as a list of (length-two) lists of operators.

Because of this the output of choi_to_kraus is not a valid input for functions that expect Kraus operators. For example, kraus_to_choi and choi_to_kraus are not inverse functions as they should be,

>>> kraus_to_choi(choi_to_kraus(phi))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/davide/miniconda3/envs/toq/lib/python3.9/site-packages/toqito/channel_ops/kraus_to_choi.py", line 66, in kraus_to_choi
    dim_op_2 = kraus_ops[0][0].shape[1]
IndexError: tuple index out of range

[dfacoet]

I had a better look at the function. I had missed the fact that it only works for channels where input and output have the same dimension, and it computes a Kraus representation in which the left and right operators are the same. So the representation as list of lists is redundant (it amounts to duplicating the output). Still, I think it would be best for the output of choi_to_kraus to be a good input for other functions in the package.

[vprusso]

Gotcha. Would you think this would have been easier to spot if the docs were written differently?

Also, perhaps either this issue should be adapted or a new one created for reducing the redundancy of the output? Would you say that aligns with what you posted here?

[dfacoet]

I do think that the docs could be a bit more specific (but it's definitely not urgent, they are good enough).

Also, perhaps either this issue should be adapted or a new one created for reducing the redundancy of the output? Would you say that aligns with what you posted here?

I am not sure what the best way to proceed is, but I think it's important that the output of choi_to_kraus be valid input for the other relevant functions in the package. Perhaps a better way to handle this in the long term would be to require the other functions to accept a (1d) list of Kraus operators as input, and assume that left and right operators are the same (which I think is often the case in practice). This would avoid redundancy, while making the representation consistent between different functions, and leaving the flexibility of specifying different left/right operators if needed. It seems that e.g. apply_channel already does this.

[vprusso]

Gotcha. I might need to do some digging on this as I can't quite recall this fact, but I don't believe one can always assume that the left and right Kraus operators will be distinct, so I think, while usually redundant to specify both, it can sometimes be necessary to be explicit as they can sometimes differ. Or at least, that is my recollection.

[dfacoet]

A representation with the same operators acting on the left and on the right exists if and only if the map is completely positive. This is why the Kraus representation is often introduced with a single list of operator (e.g. in Nielsen&Chuang). The book by Watrous seems to have a more general outlook, introducing the "two-lists" representation first, and then giving the characterization above (theorem 2.22).

[vprusso]

I've gone ahead and created an issue here: https://github.com/vprusso/toqito/issues/79

I think the captures the gist of what you're mentioning here, but of course, if I've missed some salient detail, please do either let me know or feel free to add a comment to the above issue so I can write it more properly/correctly.

And of course, if you think you'd like to take a stab at that (assuming I'm not missing something from my interpretation of what you wrote), by all means, have at it. Likewise, if I can lend a hand with someone as well, please do not hesitate to ask.

[dfacoet]

Hi @vprusso, thank you for creating the new issue, I agree that it captures what I was saying here, and suggests a good way to solve the inconsistency. I will try to do it.