`repartition` unexpected behaviour

[VictorVanthilt]

Im using a lot of permute calls where all of the indices are in order, for example:

T = zeros(Int, (ℂ^1 ⊗ ℂ^2) ← (ℂ^3 ⊗ ℂ^4 ⊗ ℂ^5 ⊗ ℂ^6))

space(permute(T,  ((1, 2, 3), (4, 5, 6)))) -> (ℂ^1 ⊗ ℂ^2 ⊗ (ℂ^3)') ← (ℂ^4 ⊗ ℂ^5 ⊗ ℂ^6)

When I found out about the repartition command I thought this was the perfect match for my overly long permute calls.
However, when I try to use it in the way I understood from the docstring, I get a totally different result:

space(repartition(T, 3, 3))) -> (ℂ^1 ⊗ ℂ^2 ⊗ (ℂ^6)') ← (ℂ^3 ⊗ ℂ^4 ⊗ ℂ^5)

are (ℂ^1 ⊗ ℂ^2 ⊗ (ℂ^6)') really the "first 3 spaces" of T? Lets check using space

space(T, 1), space(T, 2), space(T, 3) ->  ℂ^1, ℂ^2, ℂ^3'

What is the intended behaviour and is there value in adding a repartition_inds that respects space's convention about the ordering of the spaces?

[lkdvos]

The confusion originates from the fact that repartition is a planar operation, using transpose behind the screens. This means that really, what's going on is the usage of an isomorphism between V <- dual(W) and V * W.
Because of this duality, migrating spaces from domain to codomain and vice-versa reverses the order: V <- dual(W1 * W2) = dual(W2) * dual(W1) is isomorphic with V * W1 * W2

Now, there are two possible ways of establishing a linear ordering for the spaces of a TensorMap. As an example, consider t : V1 * V2 * V3 <- W1 * W2.

1. We use the order in which they were just written down, i.e. V1, V2, V3, W1, W2. This is also the order in which the indices are expected in an @planar or @tensor call, and the meaning of the Index2Tuple permutations. Additionally, this is the order that space uses. (*)
2. We use a graphical-inspired order that starts from the first space and then enumerates the remaining spaces counter-clockwise. This leads to V1, V2, V3, W2, W1. As repartition is only allowed to transpose, this remains invariant under these operations, as the only planar operations that are allowed cyclically permute this.

Both options have their advantages and disadvantages, but you cannot use both at the same time. I would guess that you are considering permute(t, ((1,2,3),(4,5,6))) as permuting with (1,2,3,4,5,6), but that is not entirely what that syntax means. If you were to draw that permutation (right to left convention), you are taking the index from the top right and migrating it to the bottom left, which is clearly not planar.

For a more concrete example, the reason we defined MPOTensor as West * South <- North * East is precisely this, because MPSKit wants to remain planar this is the only way to avoid having to do permutations.

I'm not sure if there is a big advantage to also defining a kind of repartition that changes the order differently in TensorKit itself, but keep in mind that there is nothing stopping you from doing that locally if you want :)

---

(*) space has the additional quirk that it returns the given space as if it were in the codomain. This is just a convention I think, and while I would say that it might have been better to not do this, it would now be incredibly breaking to change that...

[VictorVanthilt]

Ok thanks for the clear explanation! I will just stick to locally defining my own version of repartition.
I do think that the docstring of repartition could be a bit more descriptive:

Return tensor tdst obtained by repartitioning the indices of t. The codomain and domain of tdst correspond to the first N₁ and last N₂ spaces of t, respectively.

using "spaces" here for me suggests that space(T, 3) is the third space according to repartition which is not the case. The fact that repartition can only use transpose is also not mentioned in the docstring as far as I know.

[lkdvos]

That's very fair. I guess I was not really thinking too much about how clear it was since I was already used to this function from the fusiontree manipulations... Do you want to try and write something better?

[VictorVanthilt]

I will put it on my todo list!

[Jutho]

For clarity, it can be useful to make an analogy with how you would denote a 4-point fermionic operator with creation and annihilation operators: You would probably want to write something like

O_{i1 i2; j1 j2} a'_i1 a'_i2 a_j2 a_j1

The order of the indices in O is such that you can think of combining (i1i2) and (j1 j2) in a single row and column index of a matrix O. But in the list of creation and annihilation operators you want to interchange the order in the annihilator part, as you would otherwise get incorrect signs if you start applying/composing such operators.

So while TensorMaps have their indices labeled in the order i1 i2 j1 j2 as O, any planar operation (technically, anything that only uses duality and not braiding) is about repartitioning (and cyclicly permuting in the case of transpose) the indices in the order (i_1 i_2 j_2 j_1), and then mapping it back to the other convention. This is very annoying indeed, but it does not seem like there is a way around.