Change frobeniusschur factor

[lkdvos]

This is a small change that fixes some issues encountered with transposing and adjoints not commuting. We've traced the origin to being that while we aren't assuming the Frobenius Schur factor is +-1, we have no checks for that since for all our sectors this is true.

There is definitely a conj missing, and the one I added here seems to resolve the issue, but I absolutely did not think through whether or not it should be here, or here instead:

https://github.com/Jutho/TensorKit.jl/blob/ef03d19f8add057074c8103470dc15d759e8cd43/src/fusiontrees/manipulations.jl#L309

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.85%. Comparing base (ef03d19) to head (454a8e1).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #260   +/-   ##
=======================================
  Coverage   82.85%   82.85%           
=======================================
  Files          44       44           
  Lines        5757     5757           
=======================================
  Hits         4770     4770           
  Misses        987      987           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Jutho]

I am a bit confused; how did you find this one? This is unrelated to #245 , right? Since that would not be fixed by this extra conj? I think it is fair to assume frobeniusschur factors to be ±1. They need to have this value for a == dual(a), and all other sectors one can in principle always choose a gauge such that they are one. I believe this is mentioned in the documentation, but it is true that we do not clearly state this or test this.

[lkdvos]

This is indeed unrelated to that issue. We bumped into this because the A4 data does not respect this gauge choice, i.e. there we only have frobeniusschur(a) * frobeniusschur(dual(a)) = 1, so frobeniusschur(a) = conj(frobeniusschur(dual(a)) an arbitrary phase.

In particular, I found the following:

using MultiTensorKit, TensorKit

AC = ones(ComplexF64, Vect[A4Object]((2, 6, 1) => 1) ⊗ Vect[A4Object]((6, 6, 4) => 1) ← Vect[A4Object]((2, 6, 2) => 1))

AC2 = fill!(repartition(AC, 3), 1)
AC2.data[2] = 0
t1 = copy(transpose(AC2', ((1,), (2, 3))))
t2 = transpose(copy(AC2'), ((1,), (2, 3)))

In this case, t1 != t2 even though it should be, and by inspecting the values compared to the norm contraction I think I deduced that t2 is wrong here (although I don't fully remember how I got to that conclusion.)
The two tensors do coincide with this PR.

I'm fine with making the choice of only supporting $\pm 1$, but this does not seem to be reflected by the code, which already contains some conj around frobeniusschur values in some cases.
@lalooten might be slightly unhappy to have to re-gauge the data again though...

[Jutho]

Ok, I agree that I have been using conj(frobeniusschur(...)) and frobeniusschur(dual(some_sector)) at other places as well, so I will check for consistency.

Maybe another question for @lalooten , it would be good to have a test case for all our functionality, and that could be treated as a sector with unique fusion, but that we then compare to the SimpleFusion and GenericFusion implementation as well. Maybe something $\mathrm{Vec}_\mathsf{G}^\omega$ for a simple group $\mathsf{G}$ with a nontrivial 3-cocycle $\omega$ that has complex phases. What would be the simplest example?

[lalooten]

I don't mind either way, regauging such that the FS is always ±1 is not difficult, but on the other hand it if it does not impact efficiency it might be nice to allow it to be complex.

Regarding a simple example, $$\mathbb Z_3$$ has complex 3-cocycles, so this one would work.

[Jutho]

Yes, Z3 is what I thought. Can you remind me where to find the cocycle formula to use?

[lalooten]

For Z_n, the 3-cocycles are given here: https://mathoverflow.net/a/157012, might be worth it to just implement this for general $Z_n$

[Jutho]

Thanks; do you by any chance know if it still possible to give $\mathrm{Vec}_{\mathsf{G}}^\omega$ a braiding when $G$ is an abelian group (such as $\mathbb{Z}_N$)? This seems to be the case for the $\mathbb{Z}_2$ case, where you get the semion category, but does it extend to higher $N$?

[lalooten]

For general abelian groups with general 3-cocycles, this is not true; there is a 1-1 correspondence between braided fusion categories $\text{Vec}_G^\omega$ (which of course requires G to be abelian) and something called pre-metric groups (finite abelian group with a quadratic form). One can construct the associator and braid matrices from the quadratic form, but this does not exhaust all possible associators meaning that not all choices of $\omega$ will allow for a braiding.

For $Z_N$, I think it is true that for any choice of 3-cocycle you can find a braiding. I had a quick look and I couldn't find a reference that gives explicit expressions for this case, but there are general expressions given a quadratic form. It's probably not too hard either to guess the solution by looking at the hexagon equations, and if you really need it for something I'm happy to look into it, but it takes a bit of work.

[Jutho]

No that is fine, I think I can go with NoBraiding for now, or maybe add a braiding for the trivial cocycle case.

[Jutho]

I am going to merge this, as you are definitely correct that there needs to be a conj here. I would like to rewrite the whole foldright method to be a bit more clear but will do this separately.