Conversation
Several high-level Meataxe functions were much, much slower for
irreducible modules than their low-level counterparts (the ones
which *only* work for irreducible modules).
As an example, consider this test input:
n:=10;; # increase this to make the effect even stronger
G:=GL(56,GF(25));;
H:=Subgroup(G, Concatenation(GeneratorsOfGroup(G),List([1..n],i->PseudoRandom(G))));;
Then before these changes, we had:
gap> MTX.Indecomposition(NaturalGModule(H));; time;
1818
gap> MTX.IsomorphismModules(NaturalGModule(H),NaturalGModule(H));; time;
5408
After these changes:
gap> MTX.Indecomposition(NaturalGModule(H));; time;
22
gap> MTX.IsomorphismModules(NaturalGModule(H),NaturalGModule(H));; time;
23
To some extent this papers over a deeper issue: the general code in
MTX.Indecomposition and MTX.BasisModuleEndomorphisms ought to be way
faster: it is trivial to take the example here and e.g. form a direct
sum of modules to make it slow again.
fingolfin
added
kind: enhancement
fingolfin
changed the title
MTX.IsomorphismModules, MTX.Indecomposition, MTX.BasisModuleEndomorphisms, MTX.BasisModuleHomomorphisms)
ThomasBreuer
approved these changes
Mar 23, 2026
Contributor
ThomasBreuer
left a comment
ThomasBreuer
left a comment
There was a problem hiding this comment.
Looks good.
Thanks.
limakzi
approved these changes
Mar 23, 2026
Co-authored-by: Thomas Breuer <sam@math.rwth-aachen.de>
fingolfin
added a commit
to gap-packages/ClassicalMaximals
that referenced
this pull request
Mar 30, 2026
This started to fail since gap-system/gap#6276 But I tripled check everything there: the GAP change is fine, it just happens to return a different isomorphism which is not symmetric (however, it is symmetrizable). We could try to fix this properly, but since the underlying module is also not absolutely irreducible, it is not clear whether this test is even meaningful. So just disabling it seems fine.
fingolfin
added a commit
to gap-packages/ClassicalMaximals
that referenced
this pull request
Mar 30, 2026
This started to fail since gap-system/gap#6276 But I tripled check everything there: the GAP change is fine, it just happens to return a different isomorphism which is not symmetric (however, it is symmetrizable). We could try to fix this properly, but since the underlying module is also not absolutely irreducible, it is not clear whether this test is even meaningful. So just disabling it seems fine.
cdwensley
pushed a commit
to cdwensley/gap
that referenced
this pull request
Apr 1, 2026
…X.IsomorphismModules`, `MTX.Indecomposition`, `MTX.BasisModuleEndomorphisms`, `MTX.BasisModuleHomomorphisms`) (gap-system#6276) Several high-level Meataxe functions were much, much slower for irreducible modules than their low-level counterparts (the ones which *only* work for irreducible modules). As an example, consider this test input: n:=10;; # increase this to make the effect even stronger G:=GL(56,GF(25));; H:=Subgroup(G, Concatenation(GeneratorsOfGroup(G),List([1..n],i->PseudoRandom(G))));; Then before these changes, we had: gap> MTX.Indecomposition(NaturalGModule(H));; time; 1818 gap> MTX.IsomorphismModules(NaturalGModule(H),NaturalGModule(H));; time; 5408 After these changes: gap> MTX.Indecomposition(NaturalGModule(H));; time; 22 gap> MTX.IsomorphismModules(NaturalGModule(H),NaturalGModule(H));; time; 23 To some extent this papers over a deeper issue: the general code in MTX.Indecomposition and MTX.BasisModuleEndomorphisms ought to be way faster: it is trivial to take the example here and e.g. form a direct sum of modules to make it slow again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several high-level Meataxe functions were much, much slower for irreducible modules than their low-level counterparts (the ones which only work for irreducible modules).
As an example, consider this test input:
Then before these changes, we had:
After these changes:
To some extent this papers over a deeper issue: the general code in
MTX.IndecompositionandMTX.BasisModuleEndomorphismsought to be way faster: it is trivial to take the example here and e.g. form a direct sum of modules to make it slow again. But this is out of scope for this PR (and to an extent a known issue).Resolves #6271