Experimental: Add BasisLieHighestWeight

[lgoettgens]

This is another try to #2115 and #2402 (now on my fork so I can manage access rights myself).

Background: This is code written mainly by @BenWilop (student assistant in Aachen) that is needed for and referenced in the book chapter of @gfourier and Xin Fang. I will be helping them a bit to "oscarify" everything.

@BenWilop please continue working on this branch. If you encounter any access rights issues, please write me an email.

@ everyone please wait with reviews and comments for a bit, this PR is currently just to enable collaboration.

[codecov]

Codecov Report

Merging #2936 (bd11db1) into master (6fd21c5) will increase coverage by 0.09%.
The diff coverage is 95.47%.

@@            Coverage Diff             @@
##           master    #2936      +/-   ##
==========================================
+ Coverage   80.18%   80.27%   +0.09%     
==========================================
  Files         473      487      +14     
  Lines       67316    67846     +530     
==========================================
+ Hits        53974    54464     +490     
- Misses      13342    13382      +40     

Files	Coverage Δ
...BasisLieHighestWeight/src/BasisLieHighestWeight.jl	100.00% <100.00%> (ø)
...imental/BasisLieHighestWeight/src/MonomialOrder.jl	100.00% <100.00%> (ø)
...erimental/BasisLieHighestWeight/src/NewMonomial.jl	100.00% <100.00%> (ø)
...mental/BasisLieHighestWeight/src/RootConversion.jl	100.00% <100.00%> (ø)
...rimental/BasisLieHighestWeight/src/TensorModels.jl	100.00% <100.00%> (ø)
...rimental/BasisLieHighestWeight/src/WeylPolytope.jl	100.00% <100.00%> (ø)
...l/BasisLieHighestWeight/test/MainAlgorithm-test.jl	100.00% <100.00%> (ø)
.../BasisLieHighestWeight/test/RootConversion-test.jl	100.00% <100.00%> (ø)
...erimental/BasisLieHighestWeight/src/LieAlgebras.jl	97.43% <97.43%> (ø)
...al/BasisLieHighestWeight/src/BirationalSequence.jl	20.00% <20.00%> (ø)
... and 4 more

... and 2 files with indirect coverage changes

[lgoettgens]

Some ToDos for the future (not in this PR):

• Merge the LieAlgebraStructure here with Lie algebras from root systems, once they have all the needed functionality
• Add docs
• Excise MBOld.jl and replace with better property-based testing, or serialize some test cases to test against

[micjoswig]

OK, there is an experimental LieAlgebra type, and now there is also LieAlgebraStructure. This looks a bit weird to me. Please enlighten me about your goals.

[lgoettgens]

LieAlgebraStructure is only there to exist temporarily (as a thin wrapper around), as LieAlgebra currently does not support everything that is needed here. As already noted in #2936 (comment), this is on the todo-list to merge. But as that involves more work of different people (e.g. @felix-roehrich), and is mostly unrelated to the stuff here, I would like to move that piece of work to a future PR.

[micjoswig]

The Demazure stuff needs to be compared and probably unified with the existing function demazure_character, which already exists in the polyhedral section of the source code.

I had just discussed with @tbrysiewicz that it would make sense to move that function near the algebra or group theory sections.

Calling polymake through the Polymake.jl interface is undesirable, unless there is a specific reason. Instead you should use the existing interface which is explained, e.g., in this OSCAR book chapter. This should also simplify your code, e.g., because there is no need for you to explicitly homogenize. You might want to talk to @benlorenz .

[gfourier]

The Demazure stuff needs to be compared and probably unified with the existing function demazure_character, which already exists in the polyhedral section of the source code.

Yes, this Demazure stuff has to be generalized (beyond type A as in the polyhedral section) and then maybe moved to a Lie algebra section.

[lgoettgens]

The Demazure stuff needs to be compared and probably unified with the existing function demazure_character, which already exists in the polyhedral section of the source code.

I had just discussed with @tbrysiewicz that it would make sense to move that function near the algebra or group theory sections.

Calling polymake through the Polymake.jl interface is undesirable, unless there is a specific reason. Instead you should use the existing interface which is explained, e.g., in this OSCAR book chapter. This should also simplify your code, e.g., because there is no need for you to explicitly homogenize. You might want to talk to @benlorenz .

I am a bit confused about what you are talking about here @micjoswig. Could it be that you are looking at an old revision of this? In the current form of this PR, all Demazure functionality has been purged. Furthermore, the code calling polymake has already been changed more than a week ago (to this: https://github.com/oscar-system/Oscar.jl/pull/2936/files#diff-5cb6cccdda2ba91185fae3c9bd3d4dc0e0ddd32b4e8f3044dc3c622ce8f60f2fR89).

[micjoswig]

OK, probably I looked at the wrong thing. Pull requests from forks continue to confuse me.

[micjoswig]

OK, I don't understand all the details, e.g., for lack of GAP background. But essentially this looks alright for now.

The best way of dealing with Dynkin diagrams (e.g., in terms of interfaces) should probably be discussed with @ulthiel .

One more thing: please employ @docs to make the existing documentation also available in the generated HTML docs. Can't hurt to throw in a few more words of explanations.

[lgoettgens]

I just added all docstrings to a documentation page. Could we get this merged once CI succeeds? Or are there any other objections?