permute for anyonic tensors when it can be done without braiding

[mhauru]

The changes we discussed. Probably not ready for merging, you may want to restructure things. Works for the cases I've needed so far though.

Based on #44, so includes all those commits as well.

[Jutho]

Some thoughts:

1. There definitely needs to be a method that does this kind of manipulation on the fusion trees. Then the corresponding tensor implementation is much simpler, just like with braided addition.

2. It should be distinct from permute/braid because it is a different operation; you use a different unit (to use category slang) for bending the domain to the codomain (while using the same to bend from codomain to domain). The result is that it is only with braid up to the extra twist, however see (4). Hence, even for fermions it could already a different operation. I was thinking of calling this transpose, which Numpy seems to use for permute, so there is some analogy. In addition, without additional arguments, transpose would bend all domain to the codomain and all codomain to the domain, exactly to how transpose (a.k.a adjoint mate) is defined in rigid categories (https://jutho.github.io/TensorKit.jl/latest/man/categories/#ss_dual). With extra arguments, you can then specify to only bend some domain indices to the codomain, and some codomain indices to the domain. The transpose function currently exists for tensormaps (without additional arguments), and indeed uses the braid plus twist approach. It could then be replaced by a simpler implementation which just calls transpose on the fusion trees.

3. The question is then, which one should add! use, should it be permuting/braiding or should it be transposing (when possible). We probably want both. For bosons, there is no distinction. For anyons, you don't need extra hight/level arguments for transposing, whereas you do for braiding, so the number of arguments could tell the difference. Fermions are the odd ones; you don't need extra arguments for braiding, i.e. you can permute, but nonetheless the twist is non-trivial and so the two operations differ.

4. From a conceptual point of view, it would be better not to implement transposing via braid plus twist, but using the Asymbol (https://jutho.github.io/TensorKit.jl/latest/man/categories/#ss_topologicalfusion). Indeed, there could be a fourth BraidingStyle which is NotBraided. This particular transpose operation, and evaluating planar diagrams more generally, does not require the underlying category to be braided.

[mhauru]

I agree with this being separate from permute and braid, the current implementation was just to get the end-user MERA code to work with minimal changes to @tensor. transpose sounds sensible. A question about it though: Does it need to come with a fixed direction of rotation, clockwise or anti-clockwise? Are there categories for which it would make a difference which way you turn? If not, it could optimise the direction of rotation to minimise the number of bends.

For add!, the safest thing would probably be to have an extra argument for how to change index order, with a default value that that gives an error if the different possible choices would make a difference for the current tensor type (and maybe even for the current permutation?). As a user I would find this less confusing than significant changes in behavior based on numbers of arguments. And in practice, I don't think people are going to be calling add! much except through @tensor, and if there's going to be a separate macro to handle non-bosons, then that would be the place to make the decision then, on whether to use braid or transpose.

[Jutho]

I agree with this being separate from permute and braid, the current implementation was just to get the end-user MERA code to work with minimal changes to @tensor. transpose sounds sensible. A question about it though: Does it need to come with a fixed direction of rotation, clockwise or anti-clockwise? Are there categories for which it would make a difference which way you turn? If not, it could optimise the direction of rotation to minimise the number of bends.

If you start reading about general categories, then yes there are separate notions of left and right duality, and they come with left and right transposes (adjoint mates), corresponding to clockwise or anticlockwise rotations. And they can be distinct. This then also requires that you introduce separate left and right dual objects associated with e.g. the simple objects. In particular, the left dual of the right dual is the object itself (or could at least be identified with it, i.e. it's isomorphic), but e.g. the double left dual could be a distinct (non-isomorphic) object. However, I don't know of any practical example where this is true (at least finite-dimensional, technically, I think there are issues with the double dual of an infinite dimensional Hilbert space not being the same nor isomorphic to the original Hilbert space). So I didn't want to go to that level of generality. A pivotal structure in a category is what provides an isomorphism between left and right dual objects. But it's a functor, meaning that those isomorphisms also identify left and right transposes of morphisms. Now I assume that all those isomorphisms really mean, being identical. So our minimal assumption is that categories are pivotal, and I guess also spherical, meaning that we do not distinguish between left and right traces. See (https://jutho.github.io/TensorKit.jl/latest/man/categories/#ss_dual) for more.

[mhauru]

Closing, since master now has it's own implementation of this functionality.