Remove Choi type (?) - Githubissues

Before the first release, we should decide if we need the Choi type. Advantages of having it are:

You can use it for dispatch, so if there is a function that would have the same exact interface but two different behaviors depending on if it is a Choi type or just an MPO/LPDO, the Choi type can be used for dispatch. However, this can also be done by checking for "Input" and "Output" tags.
It can make it clearer to the user that it is a special object with more indices, not just a normal LPDO/MPO. However, you can tell that by just printing the indices anyway.
There may be many special functions particular to Choi matrices, like measuring observables or projecting onto a product state, so that might warrant having a unique type.

Disadvantages are:

In many ways, the Choi matrix acts like a normal MPO/LPDO. For most MPO/LPDO functions, we can make them work generically with the extra indices, so I think most Choi matrix functions will end up being exactly the same as MPO/LPDO functions.
In order to make the Choi matrix type useful, we will have to overload many functions that are already defined for MPO/LPDO (think about all of the linear algebra functions like tr, inner, etc., all of the distance functions, getindex and setindex!, priming and tagging functions, gauging, etc.). This could be done by making code more generic, for example making an AbstractMPO type that the Choi, MPO, and LPDO are all subtypes of (so then in general, functions are written in terms of AbstractMPO). However, it would be much simpler to just not have a Choi type.

I would lean towards removing the Choi type, and determining if it is Choi-like based on context or by analyzing index tags (or hopefully not needing to and having generic code that works for Choi and non-Choi matrices, like for example tr). We could even just make a function ischoi(::Union{MPO, LPDO}) so then we can choose special behavior for Choi-like matrices as needed.

GTorlai / PastaQ.jl

Remove Choi type (?) #147