As brought up in #227, there is an inconsistency with the interaction between FusionStyle(I) isa UniqueFusion and the implementation of foldright.
After digging a bit deeper, I was able to locate the source of the inconsistencies:
using TensorKit, TensorKitSectors
using CategoryData
const Semion = Object{PMFC{2,1,0,1,1,0}}
f₁ = FusionTree{Semion}((2, 2), 1, (true, false), ())
f₂ = FusionTree{Semion}((1,), 1, (true,), ())
TensorKitSectors.FusionStyle(::Type{Semion}) = TensorKitSectors.UniqueFusion()
only(values(TensorKit.foldright(f₁, f₂))) # 1
TensorKitSectors.FusionStyle(::Type{Semion}) = TensorKitSectors.SimpleFusion()
only(values(TensorKit.foldright(f₁, f₂))) # -1
Even though the fusion rules are the same as for Z2Irrep, the non-trivial Fsymbols make it such that the resulting coefficients differ by a minus sign.
Basically, bypassing the insert calls through https://github.com/Jutho/TensorKit.jl/blob/0c73bd2ff03dee9b6eb597863d0dbdcefce4ab3b/src/fusiontrees/manipulations.jl#L354 is not allowed.
There are some options to resolving this: we could clarify that UniqueFusion really assumes trivial Fsymbols, therefore making the code correct again. This is slightly unfortunate given the name of UniqueFusion, but would definitely be an easy fix that also doesn't alter existing performance.
Alternatively, we can "fix" foldright by not assuming trivial Fsymbols, which might deteriorate performance for the actual trivial cases, but this might not make a large difference? This more or less reverts to getting rid of that special case.
Finally, we can consider having more traits to distinguish further between these different kinds of behavior.
I'm not sure what you think @Jutho, but I would lean slightly towards the first solution, given that it is very likely that there are more parts of the code that make the assumption that UniqueFusion means we can assume trivial Fsymbols. I would also be okay with expanding the set of traits, but that takes slightly more consideration.
As brought up in #227, there is an inconsistency with the interaction between
FusionStyle(I) isa UniqueFusionand the implementation offoldright.After digging a bit deeper, I was able to locate the source of the inconsistencies:
Even though the fusion rules are the same as for Z2Irrep, the non-trivial Fsymbols make it such that the resulting coefficients differ by a minus sign.
Basically, bypassing the
insertcalls through https://github.com/Jutho/TensorKit.jl/blob/0c73bd2ff03dee9b6eb597863d0dbdcefce4ab3b/src/fusiontrees/manipulations.jl#L354 is not allowed.There are some options to resolving this: we could clarify that
UniqueFusionreally assumes trivialFsymbols, therefore making the code correct again. This is slightly unfortunate given the name ofUniqueFusion, but would definitely be an easy fix that also doesn't alter existing performance.Alternatively, we can "fix"
foldrightby not assuming trivial Fsymbols, which might deteriorate performance for the actual trivial cases, but this might not make a large difference? This more or less reverts to getting rid of that special case.Finally, we can consider having more traits to distinguish further between these different kinds of behavior.
I'm not sure what you think @Jutho, but I would lean slightly towards the first solution, given that it is very likely that there are more parts of the code that make the assumption that
UniqueFusionmeans we can assume trivial Fsymbols. I would also be okay with expanding the set of traits, but that takes slightly more consideration.