Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement computing center of endomorphism algebra of a group module (in positive characteristic) #4660

Open
fingolfin opened this issue Feb 27, 2025 · 4 comments
Assignees
Labels
enhancement New feature or request topic: groups

Comments

@fingolfin
Copy link
Member

Based on discussion with @fieker and @thofma regarding what we need to implement the Meataxe in char 0:

We need an efficient way to compute the centralizer of $E:=\mathrm{End}_G(M)$, where M is a $G$-module. Of course can do this by computing (as basis of) $E$ first, via GAP.Globals.MTX.BasisModuleEndomorphisms, but actually the code computing the endomorphisms computes the center as a byproduct (at least implicitly). So this is a matter of keeping this information during the computation (possibly if a suitable flag is provided).

So this requires changes to GAP for now.

I'd like to note that the central GAP function for this is SpinHom which has a comment suggesting it dates back to ~1996, and then this nugget:

However, this routine is nowhere near as good as the Magma algorithm, and I do not know how to improve it.

So down the road we should also look into implementing better/newer algorithms in GAP or Julia (hoping that there are papers outlining what they do -- let's collect references here if anyone knows some). Though for now the GAP code for matrices in small characteristic is faster than what we have in OSCAR, so those should be used for now until we get the better linear algebra in OSCAR ready.

@fingolfin
Copy link
Member Author

As for sources, I had a look at the "Handbook of Computational Group Theory" which discusses computing Hom_G(V,W) in section 7.5.2. It describes a basic algorithm and then says this at the end of page 241 / start of page 242:

There are better methods available when the dimensions are large, but we shall not discuss them any further here. One such method was proposed by Schneider in [Sch90a], and further unpublished ideas have been proposed by C.R.Leedham-Green, and are used in the MAGMA implementation.

"Unpublished ideas" sigh

@fingolfin
Copy link
Member Author

@fingolfin
Copy link
Member Author

Next there is https://doi.org/10.1006/jsco.2001.0454 which also gives us a hint where the code in GAP comes from:

Leedham-Green implemented an unpublished algorithm for computing endomorphism rings, which is included in Magma (Bosma et al., 1994). Smith includes an implementation of a randomized algorithm in the AutAG share package included in GAP version 3.4.4 (Schönert et al., 1995). The algorithm is tuned for modules over group algebras. The comments in the source code state that the algorithm is based on discussions with Leedham-Green, Lux, and Niemeyer, but that its performance is not as good as the implementation in Magma.

(The linked paper by Green-Heath-Struble itself is not that useful, it relies on a GAP package "Hopf" that I've never seen, though I found this old email in the GAP forum archive; it seems to use a long-dead (?) system "Opal: A system for computing noncommutative gröbner bases")

This entire situation is extremely frustrating.

@ThomasBreuer
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request topic: groups
Projects
None yet
Development

No branches or pull requests

2 participants