Add named ProductSector

[lkdvos]

This adds a small convenience feature to also allow NamedTuple in the ProductSector field type. In principle this should all be compiled away and be as efficient as the regular ProductSector, but it might be nice to use this for defining/"standardizing" specific symmetry types.

For example:

using TensorKitSectors
HubbardSymmetry = @NamedProductSector{parity::FermionParity, particle::U1Irrep, spin::SU2Irrep}
Vect[HubbardSymmetry]((0, 0, 0) => 1, (1, 1, 1/2) => 1, (0, 2, 0) => 1)

Definitely open to suggestions about syntax, printing, utility etc

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 21 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/product.jl	80.00%	21 Missing ⚠️

Files with missing lines	Coverage Δ
src/TensorKitSectors.jl	16.66% <ø> (ø)
src/product.jl	88.05% <80.00%> (-3.46%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[Jutho]

I can see why people would want this 😄 , and I think this looks like a first good proposal. I would perhaps simply call the macro constructor @NamedSector and then make sure that we do support a ProductSector with a single field/factor very well, so that people can also use this to just clarify the physical meaning of a single symmetry. A system might for example have different U1 symmetries, of which you only want to impose one.

[Jutho]

An alternative approach would be to attach a name/label to any sector that currently exists, e.g. some wrapper sector that passes through all the calls but modifies the printing and construction etc. That would require less changes to the ProductSector case, and would enable to even label a ProductSector with a single name, but it is a bit hard to think through all the consequences and effects without really trying.

[lkdvos]

As some background: this is an idea I stole (with permission) from ITensor, where the actual use-case is I think even more sophisticated than this: one could conceive of a case where you have an enormous amount of different charges, and actually use a Dict-like storage type, where missing entries are treated as the unit of the corresponding sector. There are some questions about type-stability etc, where I think you would really have to encode all appearing sector types concretely or in a concrete Union to make things like FusionStyle etc work, but at least something like Dict{Symbol,U1Irrep} could be a reasonable thing to do.

This instead is a somewhat lightweight version of that, where the names and individual types are still encoded in the type-domain. I quite like the idea of being able to distinguish between magnetic and particle U1Irrep without having to implicitly infer this, or even having a flip_x::Z2Irrep, flip_z::Z2Irrep distinction etc. One interesting feature of the named approach is that we could also consider having a promotion system where missing names are indeed treated as identity objects, so otimes(a::@NamedSector{Na::I}, b::@NamedSector{Nb::J}) could actually promote to otimes(deligneproduct(a, unit(b))::@NamedSector{Na::I,Nb::J}, deligneproduct(unit(a), b)::@NamedSector{Na::I,Nb::J}).
I did indeed have some trouble coming up with a good way of printing/interface for it. I was hoping to not have to modify ProductSector as much, but that's of course hard to predict.

Given all of this, I agree that a cleaner approach is probably to have a different wrapper type (NamedSector seems good`) that encapsulates this, which isn't a type alias. Given that this is not urgent, I'll try and have a look at some point to implement this instead.