-
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
PQuotient throwing error for large groups #5809
Comments
@FriedrichRober the error doesn't look like something deliberate, it's just an out-of-bounds access likely caused by the As such I don't think it would be problematic if you inserted code into Perhaps @hulpke or @ThomasBreuer have additional insights. |
I think the issue is that the rank of G/G' is already 2, and thus 1 generator is infeasible. The routine should return a |
If @FriedrichRober wants to make a PR changing this code path to return |
Sure I will do it and let you know when I am finished |
So I fixed the above error, I will do a draft pull request soon.
From the documentation:
But now it doesn't look to me like the algorithm is actually doing what is written in the manual. Because the p-Quotient in the above example has 520 generators, but when I set the argument |
Indeed. The PQ takes the group of the prior layer and constructs it covering group. It then evaluates the relators in the cover to get the next quotient. In other words, the number of generators available must be able to handle the coverign group, not just the next quotient. (Would it be better if the collector was not so stubborn on the number of generators? Yes, but that's not how the code was written.)
|
Okay, so I understood this part correctly. Indeed, I think it should be more lenient with the number of generators for the covering group. Are there any known bounds on how many generators are needed at most, if we say that the resulting quotient should have at most
that the code would allow covering groups to have more generators than |
Maybe a stupid question: Is it true, that the number of generators increases strictly in each layer? This would give at least a weak criterion to return fail and to stop descending the exponent-p central series. |
because as far I understand, the number of generators |
because as far I understand, the number of generators Yes. |
Yes, it would be nice if it was more lenient, but I think there is a performance price to pay with a larger generator number. PArt of the problem is that the number of generators is initialized at the very start, not for each step. At that point, any upper bound for number of generators on lower levels will be huge (basically Nielsen-Schreier bound). |
The issue was encountered in conjuction with the package LINS in gap-packages/LINS#67.
The way I would like
pQuotient
to behave is the following. If I want to search for a p-classc
up to orderp^logord
, and if there is none to be found, I would like the function to returnfail
. Currently it throws an error instead, which is bad as this function is called as a subroutine in LINS.Example:
Since I am not sure, why it was designed to throw an error instead of fail, I wanted to ask if there are good reasons for this behaviour. If not, I volunteer to change the behaviour, I think it should be fairly easy by just checking if we try to insert too many generators into the list. But I might be wrong.
The text was updated successfully, but these errors were encountered: