Meataxe: should `MTX.IsomorphismModules` automatically delegate to `MTX.IsomorphismIrred` if appropriate?

[fingolfin]

It turns out that we have two isomorphism tester for Meataxe modules. My student found and used MTX.IsomorphismModules (sensible! given that name) but it was too slow. I started debugging, but then realized: his modules were both irreducible, and thus MTX.IsomorphismIrred was applicable, and much faster.

As an example, read this file: meataxe-iso-modules.txt ; then run this code:

gap> fail <> MTX.IsomorphismIrred(M1, M2); time;
true
16
gap> fail <> MTX.IsomorphismModules(M1, M2); time;
true
1596

Which raises some wishes and question:

1. the two functions are documented in different sections (66.9-3 and 66.10-3) -- close by, but not next to each other. So maybe each should reference the other?
2. if both input modules are known to be irreducible, shouldn't MTX.IsomorphismModules just delegate to MTX.IsomorphismIrred
3. going one further: the irreducibility check is usually (in my experience) much cheaper than the full works done by MTX.IsomorphismModules; so why doesn't it just perform those checks; and then delegate / return fail / proceed as before depending on the outcome
4. in fact: why doesn't MTX.IsomorphismIrred perform those irreducibility checks, too? After all if you called, you had a reason... being told "Error, Neither module is known to be irreducible" is not that helpful.

And at that point 4, one could basically just merge the two into one function... no?

[fingolfin]

Here is a self-contained test that reproduces the issue:

G:=GL(56,GF(25));;
H:=Subgroup(G, Concatenation(GeneratorsOfGroup(G),List([1..10],i->PseudoRandom(G))));;
M1:=NaturalGModule(H);;
M2:=NaturalGModule(H);;
MTX.IsomorphismModules(M1,M2);; time;

which gives

gap> G:=GL(56,GF(25));;
gap> H:=Subgroup(G, Concatenation(GeneratorsOfGroup(G),List([1..10],i->PseudoRandom(G))));;
gap> M1:=NaturalGModule(H);;
gap> M2:=NaturalGModule(H);;
gap> MTX.IsomorphismModules(M1,M2);; time;
5227

A big part of the slowness is due to MTX.Indecomposition being slow. Indeed:

gap> MTX.IsIrreducible(M1); time;
true
11
gap> MTX.Indecomposition(M1);; time;
1802

I think a huge chunk of time there is spent in SMTX.BasisModuleEndomorphisms which in turn just calls SMTX.BasisModuleHomomorphisms.

So I assume this (or perhaps all of the above) should also test for MTX.IsIrreducible before proceeding. And then possibly call MTX.Homomorphisms (that one only requires its first argument to be irreducible).

I will submit a patch shortly.