Some small enhancements on Sylow and Hall subgroup computations

[hungaborhorvath]

This PR is supposed to address #412 and #511

Added PCore and HallSubgroup methods for nilpotent groups.

Used SetHallSubgroup and SetSylowSubgroup to store computed Hall subgroups and Sylow subgroups.

About the nilpotent group method, I am rather unsatisfied at the moment, because the pcgs methods are currently ranked higher. If the method would be installed for finite nilpotent groups, then it would rank higher. Should an extra method for finite nilpotent groups be added, or maybe should the nilpotent method be artificially ranked higher?

[fingolfin]

This seems sensible, though I did not review it in detail so far.

But I can make the obvious standard request ... :-): Could we perhaps get some tests, at least for the new methods?

[hungaborhorvath]

Corrected some typos and added tst file. Profiling shows that almost all new lines run (actually, almost all lines relevant to Sylow or Hall subgroup computations run), except for the new HallSubgroupOp method for nilpotent groups in grp.gi:2835. The main reason is explained in #558. That is IsomorphismPcGroup is called, which will realize that the group has CanEasilyComputePcgs, and therefore run the pcgs method rather than this one.

This is actually problematic with several pcgs methods, that sometimes they have insanely high ranks, and nilpotent group methods will have no chance to run. The same would happen with SylowSubgroup, as well, but there somehow I could still test it with a finitely presented example. Probably ranks are better chosen there? How should we remedy this?

[fingolfin]

Well, did you actually check whether your method for nilpotent groups is faster in the case of groups that CanEasilyComputePcgs? In particular, for various pc and permutation groups?

[hungaborhorvath]

@fingolfin For PCore, the new method is clearly better than lib/grp.gi:2657, because that also computes SylowSubgroup, and then takes the core. Further, it cannot be better than lib/grpprmcs.gi:1357, because that handles nilpotent groups as fast as it can by manually computing the Sylow subgroup, instead of calling SylowSubgroup.

And in particular, I tried for big nilpotent permutation groups, and the permgroup method is by way faster for PCore. The main reason for this is that SylowSubgroups is called, but rather than calling the fast lib/grp.gi:2771, the pcgs method is called in lib/grppcatr:298. That is, PCore is fine as it is, but SylowSubgroup in lib/grp.gi:2771 should be ranked higher.

For HallSubgroup, for all the nilpotent pc-group examples I tried they returned the answer in about the same amount of time, there was basically no difference. The main reason is that the pcgs method basically computes these all at the same time. It would make a difference for big permutation groups, if the SylowSubgroup method for nilpotent groups would be ranked higher than the pcgs method.

In summary: the `SylowSubgroupsmethod and theHallSubgroups`` method should be ranked higher, if you agree.

BTW, does it make sense to have any of these operations for infinite groups? In my opinion it does, but according to the manual it does not. If we keep ourselves to the manual, then these methods should only be installed to groups with the IsFinite flag, and that would take care of all ranking problems.

[fingolfin]

I don't know of a definition of Sylow and Hall subgroups for infinite groups, so I don't think they should be available for such groups (unless you know of a good definition? and a way to actually compute something with that definition ;-)

I am not quite sure what you mean when you say "In summary: the SylowSubgroups method and the HallSubgroupss method should be ranked higher, if you agree." -- you switch between singular and plural, and all in all I have no idea which specific methods you are talking about here.

[hungaborhorvath]

@fingolfin Sorry, I will be more specific.

For the definition, one could call a Sylow subgroup a maximal (possibly infinite) p-subgroup, i.e. a maximal subgroup such that all its elements are of p-power order. According to the wikipedia page, for nilpotent groups the torsion group is the direct product of the Sylow subgroups, i.e. for nilpotent groups the method in lib/grp.gi:2774 would work with a slight modification (throw out generators with order infinity). I have not checked whether the wiki page is really correct, but I would if you (or anyone else for that matter) thinks that SylowSubgroups should be defined for infinite groups, as well.

https://en.wikipedia.org/wiki/Nilpotent_group

About ranking:

SylowSubgroupOp:
lib/grppcatr.gi:303 is ranked very high (I just see that its rank has an additional 100 to it).
The method in lib/grp.gi:2774 should be ranked higher than lib/grppcatr.gi:303. Maybe by removing the added 100 from lib/grppcatr.gi:303 and by either adding an IsFinite filter to lib/grp.gi:2774 or increasing the rank of lib/grp.gi:2774 by RankFilter(IsFinite) (depending on whether the method should work for infinite groups or not).

HallSubgroupOp:
lib/grppcatr.gi:153 currently also has higher rank than lib/grp.gi:2838. This could be remedied by either adding an IsFinite filter to lib/grp.gi:2838 or increasing the rank of lib/grp.gi:2838 by RankFilter(IsFinite) (depending on whether the method should work for infinite groups or not).

[bh11]

There are several (conflicting) definitions for Sylow subgroups of infinite groups. It's probably not a good idea to pick one more or less at random.

In the abelian and nilpotent cases, it would be more common to call them p-torsion subgroups.

Btw., throwing out infinite generators isn't enough: you can generate any infinite abelian group using only generators of infinite order – even in that case, you'd have to use IndependentGenerators. For nilpotent groups, you'll have to compute the torsion subgroup first.

I guess it's better to ignore the infinite cases for the moment.

[fingolfin]

What @bh11 was exactly my thought: I am aware of definitions, but I am not aware of a "good" definition -- the fact that multiple, conflicting definitions exist means that probably none of them is "good" (unless one is very, very widely used in the literature, and in some mathematical sense "better" than the others -- I am pretty sure that's not the case here).
So, I think we should stick to the well-established case, and not open up this can of worms. It would only lead to confusion.

In general, I think an important key principle is to only write code that you actually use -- because if you write code (and that includes introducing code for sylow subgroups of infinite groups) which you do not actually use yourself, actively, then most likely you got it wrong anyway ;-).

[hungaborhorvath]

Very well, I added the IsFinite filter to the nilpotent methods for PCore, SylowSubgroup, HallSubgroup.

I have not touched the 100 rank increase in lib/grppcatr.gi:303, because I am not sure why this was introduced in the first place. Maybe somebody can comment on this?

In grpprmcs.gi:1361 I have replaced the initial factorization of p and replaced it by an IsPrime check. Nevertheless, it is already superfluous, because some other method already checks for p being prime before PCoreOp is called. So I believe this could and should be removed, but probably somebody should confirm this who knows the inner workings of these KeyDependent operations better.

[markuspf]

After feedback from @hulpke in #692, I will merge this and we will see how the more intensive tests go.

[olexandr-konovalov]

@hungaborhorvath Since this PR now merged, subject to passing more intensive tests, could you please add to the Wiki page for the next major release the text to include in the changes manual and the release announcement?

[hungaborhorvath]

@alex-konovalov I wrote something, it that ok?

[olexandr-konovalov]

@hungaborhorvath yes, please only references to pull requests or issues in the same style like this is done in https://github.com/gap-system/gap/wiki/Changes-between-GAP-4.7-and-GAP-4.8. This will help a lot.

I will not ask/reply to other PRs from the current batch, but please assume that this is the default procedure to document changes for the next release - it's easier to write this text as it goes than to delay it till the release time. Thanks!

[hungaborhorvath]

@alex-konovalov Ok, I added all PR numbers, links, and the PR titles. I did, however, change some of the PR titles on this wiki page (e.g. removed finite, where the method does in fact work for infinite groups), and could not make myself remove the explaining sentences. If you or anyone else does not like them, feel free to remove them. I will add explanations for the other PRs as they are merged. Thank you for pointing this out.

[olexandr-konovalov]

Very good, thanks. There is no plan to keep the PR titles there (if you will scroll the page for GAP 4.8 until releases that happened already, you will see more polished texts), but I've put them there to ease understanding (and used italics to distinguish a temporary text from the rest). Text looks good, and with Wiki it's easy now to polish it if anybody would like.

[hungaborhorvath]

@alex-konovalov Ok, I italicized my text, and someone else can finalize it.

[olexandr-konovalov]

Thanks. I've added a note to GAP 4.8 overview saying "THIS SECTION IS IN PROGRESS - PLEASE USE THE SAME STYLE AS IN THE RECENT RELEASES, LISTED BELOW" to avoid confusions:)