- 
                Notifications
    You must be signed in to change notification settings 
- Fork 175
Open
Labels
kind: bug: unexpected errorIssues describing bugs in which computation unexpectedly encounters an error, and PRs fixing themIssues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them
Milestone
Description
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-class c up to order p^logord, and if there is none to be found, I would like the function to return fail. Currently it throws an error instead, which is bad as this function is called as a subroutine in LINS.
Example:
gap> F := FreeGroup(["a", "b"]);;
gap> a := F.1;;
gap> b := F.1;;
gap> p := 5;;
gap> G := F / [a^p, b^p, Comm(a,b)];
<fp group on the generators [ a, b ]>
gap> PQuotient(G, p, 1, 2);
<5-quotient system of 5-class 1 with 2 generators>
gap> PQuotient(G, p, 1, 1); # throws error, since we need two generators
Error, List Elements: <list>[2] must have an assigned value in
  qs!.images{generators} := gens{[ 1 .. d ]}; at /Users/friedrich/.gap/gapdev/lib/pquot.gi:1345 called from 
AbelianPQuotient( qs ); at /Users/friedrich/.gap/gapdev/lib/pquot.gi:1456 called from
<function "PQuotient">( <arguments> )
 called from read-eval loop at *stdin*:19
type 'quit;' to quit to outer loop
brk> 
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.
Metadata
Metadata
Assignees
Labels
kind: bug: unexpected errorIssues describing bugs in which computation unexpectedly encounters an error, and PRs fixing themIssues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them