Promote JuLie to src

[joschmitt]

Resolves #2301 and resolves #2462 as a start on #3147 .
I decided to be so bold to move experimental/JuLie to src/Combinatorics and did some cosmetic changes.
What else needs to be done to make this ready for src? I cannot judge the mathematics. Regarding the source code, I feel that the wording/style of the documentation is often a bit different from what we have elsewhere (e.g., the documentation mostly gives the mathematical definition of the object it returns). Other than that there are some violations of our style guide (whitespaces etc.), but I have seen worse code in src...

To do:

• make partitions etc. return an iterator
• tabs -> spaces
• lower case constructor for Tableau
• getter functions for Partition and Tableau
• Rename Tableau -> YoungTableau
• More (minor) adjustments regarding the style guide
• adjust wording of documentation
• Feature: make tableaux print fancier (even without unicode we should be able to print them better) Add display options from AbstractAlgebra.YoungTableau to Tableau #2462
• Put ascending_partitions back in experimental for the time being
• Add sanity checks to the constructors and a check keyword to disable them
• Adjust schur_polynomial to Allow polynomial rings with 0 variables Nemocas/Nemo.jl#1619 once we updated Nemo
• Decide what integer type number_of_partitions should return

More?

[joschmitt]

According to my own plans in #3147 partitions etc. should return iterators. This will require a bit more work.

[ulthiel]

According to my own plans in #3147 partitions etc. should return iterators. This will require a bit more work.

If I remember correctly, I have implemented an interator, no?

I checked and recall now: for compositions I implemented an iterator and convinced myself as well that this is the way to go. I wanted to use that as a template for implementing a partition iterator as well but didn't do it. I think it shouldn't be too difficult to modify the code (it should be the same algorithm that I implemented because it's fast).

[ulthiel]

A further thought on iterators (I was thinking a lot about this back then but then forgot everything): as far as possible for any combinatorial structure there should be an interator. There may be many different ways to generate one and the same set of combinatorial objects: different algorithms that also generate in different orders which may be very relevant in applications. Iterators should be implemented per algorithm (ParititionsXYZ, PartitionsABC, ...) and there should be a default choice of iterator. I first tried to have one common type of iterator with optional argument for algorithms. But this doesn't work because different algorithms may use different types of state vectors and one runs in type stability problems (which is bad for performance).

[joschmitt]

as far as possible for any combinatorial structure there should be an interator.

Good, then we all agree on this. From what I can see, the implementations already work iteratively, so changing this should not be too hard. But doing it efficiently etc. is also not entirely trivial. Let's see.

[codecov]

Codecov Report

Merging #3159 (937c27e) into master (070219e) will increase coverage by 0.03%.
The diff coverage is 96.96%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3159      +/-   ##
==========================================
+ Coverage   81.60%   81.63%   +0.03%     
==========================================
  Files         546      546              
  Lines       73504    73468      -36     
==========================================
- Hits        59980    59979       -1     
+ Misses      13524    13489      -35     

Files	Coverage Δ
experimental/Experimental.jl	81.81% <ø> (ø)
experimental/IntegerCombinatorics/test/runtests.jl	100.00% <100.00%> (ø)
experimental/IntersectionTheory/src/Main.jl	88.49% <100.00%> (ø)
experimental/LieAlgebras/src/LieAlgebras.jl	100.00% <ø> (ø)
src/Combinatorics/IntegerCombinatorics/types.jl	100.00% <100.00%> (ø)
src/Oscar.jl	61.03% <ø> (ø)
...edralGeometry/Polyhedron/standard_constructions.jl	96.24% <ø> (ø)
...l/IntegerCombinatorics/src/IntegerCombinatorics.jl	98.90% <98.90%> (ø)
...natorics/IntegerCombinatorics/schur_polynomials.jl	80.95% <80.00%> (ø)
...c/Combinatorics/IntegerCombinatorics/partitions.jl	97.59% <97.59%> (ø)
... and 1 more

... and 1 file with indirect coverage changes

[joschmitt]

Turning partitions etc. into iterators is still missing, but I think this pull request should be reviewed (and merged) like this. That would make it easier to review the iterator stuff later (and also make it easier for other people to help with that).

So far, there is almost no change to functionality. A quick overview of what has been done is given by the check list at the top (or the commit descriptions).

[lgoettgens]

While working on #3272, I noticed that Nemo provides its own number_of_partitions with slightly different overflow behavior. It would be great if you could unify your function with this one to reduce the friction between #3272 and this PR.

[joschmitt]

While working on #3272, I noticed that Nemo provides its own number_of_partitions with slightly different overflow behavior. It would be great if you could unify your function with this one to reduce the friction between #3272 and this PR.

Yeah, will do. This pull request isn't relevant for the book or anything so yours has priority.

[ulthiel]

Can you explain the open "Figure out why we have several ways of counting partitions (and decide on one)"? The fastest one should be the one from FLINT I think and this one should be used.

[joschmitt]

Can you explain the open "Figure out why we have several ways of counting partitions (and decide on one)"? The fastest one should be the one from FLINT I think and this one should be used.

Apparently there is another number_of_partitions in Nemo (which was named differently until the unification of functions with number_of_... names yesterday). At first glance, it calls a different C function. I didn't look into it closely yet.

[ulthiel]

Can you explain the open "Figure out why we have several ways of counting partitions (and decide on one)"? The fastest one should be the one from FLINT I think and this one should be used.

Apparently there is another number_of_partitions in Nemo (which was named differently until the unification of functions with number_of_... names yesterday). At first glance, it calls a different C function. I didn't look into it closely yet.

Okay, maybe @thofma knows? I think we should use the one from the paper by Fredrik Johansson, which should be the one implemented here: https://flintlib.org/doc/partitions.html (and this is the one I have been calling in JuLie).

[joschmitt]

This is good to go from my side (as soon as CI confirms that I didn't miss anything while renaming).

[joschmitt]

Still needs an approving review by an adult :)