IsingBimodule for testing multifusion category within TensorKit

[borisdevos]

This PR makes use of the newly introduced IsingBimodule multifusion category in QuantumKitHub/TensorKitSectors.jl#14 to test the changes in #247 within TensorKit itself. This was needed because MultiTensorKit depends on TensorKit itself.

What's new:

• leftoneunit and rightoneunit are introduced to naturally extend oneunit, but not for Type{GradedSpace{...}} because it needs to know the objects within the GradedSpace.
• artin_braid had an isone check replaced with a multifusion-friendly check (although this might be excessive, since as of now we don't consider braiding within multifusion categories)
• various custom constructors to deal with not being able to evaluate one(IsingBimodule)
• tests for IsingBimodule fusion trees, spaces and tensors
• few changes to existing tests

I left a bunch of comments everywhere to remind me of certain choices I made in the implementation. It would be nice if these were addressed. I can clean most of them afterwards, but should probably keep some of them, or at least the ones in the tests to help whoever might need to maintain those in the future.

As I started on this before #247 got merged, its commit history is here as well, and I'm not sure what kind of rebase I need to do to get rid of it. I tried something and files seemed to want to vanish, so I aborted that attempt 😅 Those luckily don't appear in the files changed though.

IsingBimodule still needs to get renamed to that, so currently everything is IsingBimod. I'm assuming we're waiting on QuantumKitHub/TensorKitSectors.jl#19 to merge to release v0.2 though.

Edit: I forgot to mention, but currently there's one thing broken which I can't find the error in. It appears in the full trace test. Ignoring the part where I don't know what to do with tracing module legs, it seems that the behavior is different for the two fusion categories in IsingBimodule. In particular, the full trace test passes for the "C" fusion category, but not for "D", the latter tracing to zero via @planar. I checked this quickly in MultiTensorKit with the multifusion category I got there, and it is consistent there.

Edit 2: I also forgot that @Jutho and I briefly discussed trying to increase code coverage, most prominently for GenericFusion but also here and there for other functions. I can do this in a separate PR.

[codecov]

Codecov Report

❌ Patch coverage is 92.95775% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.49%. Comparing base (87d4662) to head (9b5ba0b).

Files with missing lines	Patch %	Lines
src/spaces/multifusionspace.jl	91.93%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #263      +/-   ##
==========================================
+ Coverage   83.39%   83.49%   +0.10%     
==========================================
  Files          44       45       +1     
  Lines        5757     5823      +66     
==========================================
+ Hits         4801     4862      +61     
- Misses        956      961       +5     

☔ 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.

[lkdvos]

What was wrong with the previous implementations? This looks like it will always fail for multifusion things

[borisdevos]

I wanted left/rightoneunit to also work on empty spaces, because oneunit does so. This will indeed fail for multifusion things, hence the specialisation.

[lkdvos]

I see, but what do you think about this then:

function leftoneunit(V::GradedSpace{I}) where {I<:Sector}
    s = sectors(V)
    u = leftoneunit(isempty(s) ? I : first(s))
    return spacetype(V)(u => 1)
end

[lkdvos]

It's not great if we have to specialize everything specifically for Vect[IsingBimodule], since this would mean we have to redo all that work for any multifusion category. In that sense, we would either need a fusion type that specifies this, such that we can specialize properly, or write these methods in a generic way that works for everything

[borisdevos]

I'm not sure what you mean by redoing all that work. IsingBimodule should be the only multifusion category tested within TensorKit itself. This infrastructure already exists in MultiTensorKit (albeit in a PR for now), which will support all the other multifusion categories.

[lkdvos]

What I mean is that if all we are testing is the specializations that are written solely for IsingBimodule, which is used mainly for testing, this doesn't actually help all that much, since it would have to be both reimplemented and retested for other multifusion categories as well

[lkdvos]

Is there a reason for removing this t2 call?

[borisdevos]

I removed all the permutations in tests which weren't explicitely testing for permutations, which I had to do anyway for the multifusion tests. This would allow for testing anyonic sectors if we decide to expand the space list.

[lkdvos]

That's fair. I think I would like to keep both though, to actually have coverage of as much as possible. Probably it is better to just separate these things out a bit further.

[lkdvos]

It's definitely good to test both @planar and @tensor, but we probably want to test both?

[borisdevos]

This was also with expanding to non-symmetric braidings in mind. I could put a SymmetricBraiding check here to then evaluate @tensor if you want?

[Jutho]

Suggested change

	allequal(a.col for a in sectors(S)) ||
	throw(ArgumentError("sectors of $S do not have the same rightone"))
	sector = rightone(first(sectors(S)))
	allequal(rightone, sectors(S)) || throw(throw(ArgumentError("sectors of $S do not have the same rightone"))
	return spacetype(S)(rightone(first(list))=>1)