Make `Irr` faster for "most" pc groups

[fingolfin]

Consider this:

gap> G:=SmallGroup(1872,7); Irr(G);; time;
<pc group of size 1872 with 7 generators>
2277
gap> G:=SmallGroup(1872,7); IsSupersolvableGroup(G); time; Irr(G);; time;
<pc group of size 1872 with 7 generators>
true
4
39

As far as I know, IsSupersolvableGroup is rather fast. Is there a reason we don't *always( test it (and also IsAbelianGroup) before deciding to which Irr method we dispatch?

E.g. we could rename Irr to IrrOp and add a new function Irr which checks these and maybe other properties before dispatching to IrrOp.

Or maybe @ThomasBreuer has a better solution... In any case it seems odd to require the user to know such tricks...

CC: @fieker

[ThomasBreuer]

I think there is no reason not to test IsSupersolvable before calling an expensive Irr method.

Currently we have several methods for Irr( G, 0 ).

• for groups handled via nice monomorphisms (known filter IsHandledByNiceMonomorphism),
• for natural symmetric or alternating groups (known filter IsNaturalSymmetricGroup or IsNaturalAlternatingGroup,
• for groups which store already irreducibles computed by dedicated functions, such that this list is complete (known filter IsSupersolvableGroup and HasIrrBaumClausen or IsSupersolvableGroup and HasIrrConlon),
• for supersolvable groups (known filter IsSupersolvableGroup; actually there are two methods, calling IrrBaumClausen or IrrConlon, where the former is preferred),
• for groups (the method calling IrrUnger if the package InduceReduce is loaded, and the method calling IrrDixonSchneider otherwise).

(The method for IsHandledByNiceMonomorphism should probably be ranked below the methods for IsNaturalSymmetricGroup or IsNaturalAlternatingGroup.)

1. We could install a new method with high rank that checks for IsNaturalSymmetricGroup, IsNaturalAlternatingGroup, IsSupersolvableGroup, and redispatches if it finds a true result that was not yet known.
   (This approach is taken for example in the case of the operation IrreducibleRepresentations.)
2. Alternatively, the "expensive" methods themselves could do such a redispatch. In fact, both IrrUnger and IrrDixonSchneider could first call IrrBaumClausen in order to get at least a partial result, and if necessary then apply their own techniques to compute what is missing.
3. Concerning supersolvability, in fact IrrBaumClausen is enough also if the group is not supersolvable but has abelian supersolvable residuum, thus it would make sense to compute whether this holds.
   (Among the 1048 groups of order up to 100, there are 975 supersolvable groups, and only 25 have nonabelian supersolvable residuum.)
   We do not have a filter that expresses this property, the redispatch could explicitly call IrrBaumClausen if applicable.

[fingolfin]

To me option 2 seems good.

Regarding 3, won't this also be taken care of by calling IrrBaumClausen first and using its potentially partial result?

BTW, do we have a function to compute the supersolvable residuum? Should we have one?

[ThomasBreuer]

Thanks @fingolfin.

The advantage of option 1 would be that we can put the additional method into the GAP library, whereas we have to change also GAP packages for option 2.
And with option 1, one does not get misleading runtimes when one calls the individual methods.
Besides that, I am also in favour of option 2.

Yes, there is SupersolvableResiduum.
And yes, if a method (e.g. IrrDixonSchneider) anyhow calls IrrBaumClausen then explicitly computing the supersolvable residuum might be unnecessary.

If nobody objects to option 2 then I will provide pull requests for this option.

[fingolfin]

For option 2 we may have to change InduceReduce (not-yet-but-soon-in-the-distro) and UTable -- for both it now looks unlikely they'll be in 4.15.0.

So I really think we should go for 2.

[limakzi]

@fingolfin I wanted to take it, but it looks like @ThomasBreuer fixed it #6314.
It can be closed, I think.