Linear combinations of set partitions

[sebvz777]

We added the implementation of linear combinations of set-partitions.
See for example Chapter 5 in [Gro20] in the Oscar references.

[lgoettgens]

Some comments from just shortly looking at the changes.
Do you plan to have linear combinations for the other types of partitions as well?
From my view of not knowing anything about the concrete mathematics involved: I would expect that functions like +(::SetPartition, ::SetPartition) and *(::RingElement, ::SetPartition) exist and return a LinearSetPartition. Is something like this sensible (in a mathematical sense) and planned to get added?

[fingolfin]

This seems to build on the PR #2977 by @pinguly so perhaps @pinguly would like to comment on this PR / review it? As far as I can tell, both of you are students of Moritz Weber, so it would also be useful to know what role this all plays within the TRR?

[fingolfin]

@mjrodgers please have a look at this, too

[pinguly]

This pull request extends the previous one by adding linear combinations of set-partitions. These appear for example in study of quantum groups (Moritz Weber) and more generally tensor categories (Ulrich Thiel). As a concrete example, one could use these objects to implement the Temperly-Lieb algebra/category in the future.

@lgoettgens It is not clear to me what type the result of +(::SetPartition, ::SetPartition) should have or in which ring the coefficients should live. If one chooses ZZ, is there a simple way to allow the addition with partitions over other rings. Or should +(::LinearSetPartition, ::LinearSetPartition) not depend on the type of the underlying ring and just try to add the coefficients?

[codecov]

Codecov Report

Attention: Patch coverage is 86.04651% with 12 lines in your changes missing coverage. Please review.

Project coverage is 84.65%. Comparing base (71c1f3e) to head (5c3e20a).
Report is 85 commits behind head on master.

Files	Patch %	Lines
experimental/SetPartitions/src/LinearPartition.jl	83.09%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3944      +/-   ##
==========================================
+ Coverage   84.00%   84.65%   +0.64%     
==========================================
  Files         592      600       +8     
  Lines       81624    82554     +930     
==========================================
+ Hits        68566    69883    +1317     
+ Misses      13058    12671     -387     

Files	Coverage Δ
experimental/SetPartitions/src/SetPartitions.jl	100.00% <ø> (ø)
experimental/SetPartitions/src/Util.jl	100.00% <100.00%> (ø)
experimental/SetPartitions/src/LinearPartition.jl	83.09% <83.09%> (ø)

... and 103 files with indirect coverage changes

[lgoettgens]

Some more comments

[lgoettgens]

Some more comments

[lgoettgens]

Some more minor nitpicks. Once these are adapted, this is fine from my POV. (but @fingolfin asked @mjrodgers to review this as well in #3944 (comment))

Two additional things came to my mind while reading through this again. This is nothing that needs to be changed asap, just for @sebvz777 and @pinguly to think about for future work.

1. The name LinearPartition seems kind of weird. Firstly, it is not an AbstractPartition by itself, although the name may suggest that. Secondly, in the literature I found (and you referenced), these things are either called "linear combination of partitions" or "linear category of partitions", but never "linear partition".
2. For fixed S and T and d (third arg of compose), the objects of type LinearPartition{S,T} form a ring. So it would make sense to think about adding a parent object (aka the ring itself) and implementing the ring interface from AA.

[pinguly]

@lgoettgens Regarding the two additional remarks:

1. I agree that LinearPartition does not quiet fit. It should be something like LinearCategoryOfPartitionsElem but this is rather long.
2. For fixed S, T and d the linear partitions do not form a ring but a category since the composition is only defined if the points agree (we should assert and document this more explicitly). So one could implement a parent category object in the future when categories are included in Oscar.

[mjrodgers]

I agree with this most recent batch of suggestions made by @lgoettgens and think this looks good to merge into experimental as an initial commit for this package.

[lgoettgens]

All comments from above are resolved now. Once the doctests are happy, this is good to go from my POV. The above snipped should be enough to fix the doctests (I think)