-
Notifications
You must be signed in to change notification settings - Fork 161
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
Address @hungaborhorvath's pull requests #692
Comments
#552, #583, #606 circumvent the method selection to force a test for nilpotence first. I'm uncomfortable with such installations, unless a clear benefit and lack of cost in inapplicable cases can be demonstrated, #563 is a hopeless method (which the included tests actually don't test) and which I'm inclined to reject: If both N and G?n are not solvable, it is unlikely that a subgroup lattice computation ever will terminate. |
I think #549 is not the PR you mean. |
@stevelinton indeed. I just removed it. |
Regarding #552, #583 and #606, I share @hulpke's concern about circumventing method selection in this way. I think the test is in the wrong place. If you have two methods for solving a problem, where the first requires some Properties of the arguments and the second is slower (or even is just a No Method Found) it may well be sensible to try and explicitly check some of the Properties before calling the slower method. Specifically when that check will never fail when the slower method succeeds, and when the check is likely to be quicker than the slower method. However I think the place to put that check is in the slower method (or as a fallback method if there is no slower method). In particular if the slower method is changed in any way, the conditions for doing the check need to be re-evaluated. |
Mhm actually the |
I just merged #552, but split up the installed method for maximal subgroups into a case for abelian groups and a case for solvable groups. |
Thank you very much for checking these PRs. @markuspf If you break up the code to be installed for only groups having the property, you do not need the artificial rank increase, anymore. Namely, |
@hungaborhorvath I will just remove the rank increase manually. Thanks for pointing that out. |
We have two new diffs now:
While the 1st one is just the ordering, the 2nd one is strange. How did we miss it with Travis CI? |
@alex-konovalov @markuspf A In the tests that I have added I assumed that This will be an issue in all other PRs, as well. |
I am not sure whether My impression was that the methods were only supposed to be selected if the appropriate properties of the group were already known. Maybe @hulpke and/or @stevelinton can comment on that. |
Redispatch on Condition is more-or-less the official way to deal with these situations, along the lines I suggested above. Critically it is basically guaranteed to be called last, so it can’t get in the way of any method that might actually work.
|
Mhm. So I added Now in the following situation:
GAP does not know that Maybe in this case the fix is to weigh whether in the lattice method testing for nilpotency and redispatching is the correct thing to do? |
@hulpke about #563 I am sorry, I do not understand why you write that the tests do not check this method? The group A_5 semidirect S_5 is explicitly added to check this. Did I mess it up? To give some background for everybody: Currently there is no method for In #563 I added the method only for groups knowing their conjugacy classes as per @bh11 suggestion, until we do not have anything better. @hulpke mentioned during the discussion that he might write a proper code at some point. In the meantime, however, (if #563 is merged), for the problematic groups I can call |
So I merged most of the PRs, but I hacked around problems with method selection in the tests by adding explicit I can add more |
Some of the current methods should only be called for finite groups, e.g. grp.gi:4456. That way redispatch would help for infinite groups, at least. @markuspf You have missed some code from #552, grppcatr:481-483. This tests, if G/G' is infinite (for arbitrary group, not only for abelian or solvable), in which case it errors out by telling the user that there are infinitely many maximal normal subgroups. Currently you get a no method found error:
This particular problem could be handled by e.g. adding the missing code to the I have not checked all the changes in the PRs thoroughly, not even this, so there might be further problems. Is there any way I can check what exactly has been merged compared to what is on the PR links? edit: confusing typos, sorry. |
I have merged exactly the PRs, and then edited accordingly, hence you can just look at the history of the files to see what was merged, and how I changed it. I did intentionally remove the computation of |
@markuspf Ah, ok, now I understand. @fingolfin did not explicitly state, though, that it should be removed, and nobody ever replied to my reasoning on his comment. |
@hungaborhorvath we have a problem :) It is required that tests should run without packages (i.e. when GAP is started with Now this is what happens in testinstall:
The group here is constructed as follows:
and apparently some package is required to handle this.
|
Also, there are now 2 diffs in manual examples with default packages. They are harmless, the groups are actually equal. I will update them when the code will be stable. Just to report them in case anyone notices.
|
If I ever have this funny idea to just do minor edits and merge, please someone remind me of this issue. |
@hungaborhorvath I suggest you now look at the state of the code and submit new PRs for issues you find. We will have to make some statements about testing functionality somewhere, for instance testing of code in the library relying on packages, which then fail because the test is run with the option |
@markuspf I will look through all 5 PRs and their current states, look through the log, and try to fix the problems I find. It will take some time and I cannot begin until this weekend, maybe not until next weekend. :-( |
@markuspf I was about to write my concerns about how these merges were perhaps a bit hasty (resp. how I think one should not do merge + edit, but rather request the PR submitter to apply those edits first before doing the merge...). But I see you already seem to have some concerns about it yourself, so I guess that settles it ... ;-). |
Yes, apparently I had to learn this the hard way. I'll certainly not forget the experience though. |
@markuspf Do not beat yourself up on this, you did a pretty good job at rewriting the methods. I have now checked the code and made some changes corresponding to the previous PRs, see #705 for maximal normal subgroups, #711 for minimal normal subgroups and socle, and see issue #710 for deciding what should be done about Frattini subgroup computation. Further, the Sylow- and Hall subgroup PR had a bug, which is corrected in #708, and #706 tries to add abelian filters even if solvability is checked (for better method selection). |
I wasn't beating myself up (at least not over having done things wrong), just about the fact that in my desire to get this moved along I went ahead and merged your PRs creating a lot of work for myself in the process. |
Fix some issues with MaximalNormalSubgroups introduced from #692 after merging #552. - NormalSubgroup computation method is only called for finite groups. - Redispatch is added for two methods (finite, solvable). (Not added for abelian, because abelian groups should be recognized by the IsSolvabe test.) - New generic method added checking if AbelianInvariants has 0. - Abelian method checks if AbelianInvariants has 0 (for non pc-groups). - If GAP finds that there are infinitely many maximal normal subgroups, then it returns fail instead of erroring out (e.g. if 0 is in AbelianInvariants). - Manual is changed to reflect this new behaviour, an example is added, as well. - Lists are replaced by sorted lists in test file and some more tests are added.
@hungaborhorvath has submitted a number of pull requests, most of which have been commented on by multiple people. Since the issues are somehow connected, we should decide on what to do with the pull requests. The numbers are listed below for convenience.
The text was updated successfully, but these errors were encountered: