Oscar.jl
Oscar.jl copied to clipboard
oscar-system
Invariant theory pr
This is a rebase of a previous pull request (sorry, I can't find it anymore for some reason), binding it to the recent changes in https://github.com/oscar-system/Oscar.jl/pull/1537 and cleaning up the code base a bit.
We introduce group schemes in general with matrix groups as special case. For representations of the latter we provide methods to compute their invariant rings.
CC: @wdecker
For some reason, the tests try to feed my AffineMatrixGroups into commands that are for GAPGroups. That makes the doctests fail. Does anyone know why this happens? I thought I had checked that AffineMatrixGroup was not already taken (unlike MatrixGroup, for instance).
CC: @fingolfin
Edit: For the other tests, I also do not understand what is going wrong. Do my new structs involuntarily trigger extra tests that take forever to run?
You "stole" special_linear_group and general_linear_group by overloading it. Choose a different name for now.
One open question that I would like to give for discussion:
The constructor for AffineGroupScheme requires maps for multiplication, taking the inverse element, etc. I found that for many groups (already for GL(5;QQ) for instance), the inversion map A -> A^{-1} is too expensive to write down explicitly. In this case, I use Cramer's rule and even expanding the determinant seems to be too much.
How should we resolve this? Make giving the maps optional?
I am also confused: why would we add another implementation for computing invariants of matrix groups? We already have an efficient implementation. So what does this one add?
Your previous PR presumably is #696?
That was long time ago. I thought I had done another one some weeks ago. But either way, it would be deprecated by now.
I am also confused: why would we add another implementation for computing invariants of matrix groups? We already have an efficient implementation. So what does this one add?
The existing implementations are for finite matrix groups. This one is for algebraic group varieties.
Well, can #696 then be closed?
Yes.
With this PR, we still expect a few changes from internal discussions, but we plan to have it finalized by the end of the week.
As far as I know, this branch is now also essentially abandoned, is that right? Can we close it then?
We also have a student working on implementing several of the algorithms for linear reductive groups, she already has some working code, but on a much simpler level (not working with schemes or anything, just polynomial ideals, more or less matching how Magma does it). Of course it'd be nice to eventually also be able to represent e.g. SL_2(k) as a variety/scheme/whatever, but actually being able to do the computations in some way is already nice :-)
Since I have not heard any objections from either @wdecker or @HechtiDerLachs I'll close this now. It can always be reopened or resubmitted as a new PR.