Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
| TF_actual = Core.Compiler.return_type(Fsymbol, NTuple{6, I}) | ||
| TF_imposed = FusionStyle(I) isa MultiplicityFreeFusion ? Ftype : Array{Ftype, 4} # won't work for sparse arrays (CategoryData) | ||
| @test TF_actual == TF_imposed |
There was a problem hiding this comment.
I don't think this is really what I had in mind, the TF_actual should simply be scalartype(Fsymbol(...)) for concrete values, while the TF_imposed is fusionscalartype(I).
We indeed do not want to put restrictions on the type of object that is output by Fsymbol.
There was a problem hiding this comment.
But this is already being tested in
TensorKitSectors.jl/test/sectors.jl
Lines 19 to 22 in fa3956f
Though I do agree that testing types is not good
There was a problem hiding this comment.
I think that test is actually better indeed, but if you prefer to simply reorganize that a little and put these checks in a separate testset that sounds great to me too
| @test size(Fsymbol(a, b, c, d, e, f)) == F_size | ||
| end | ||
| end | ||
|
|
There was a problem hiding this comment.
We may also consider adding tests for invalid fusion channels, as I think this would be easier to have uncaught errors in
There was a problem hiding this comment.
This is tied together to a test suite that works for multifusion and fusion categories together, which remains difficult to realise 🫠 but I can differ between SimpleUnit and GenericUnit for this specific test easily if wanted
There was a problem hiding this comment.
Since that remains difficult, how about we still do that here? For example, we could already capture the non-UniqueFusion case by looping over all values, not only the intersect, which would still be "valid" fusion channels in the sense that everything is allowed to fuse according to the multifusion rules
There was a problem hiding this comment.
I think I can deal with this PR better once #71 merges
2 participants
Tackles #60. As left as comment, CategoryData stores the
GenericFusiontopological data as sparse arrays, so this will fail. Not sure if it's sufficient to just check whether everything's a subtype ofAbstractArray{T, N}?I also had some fusion ring checks lying around and decided to add them. It might be overkill, since it'll be a bunch of
0=0or1=1equations 🫠