g/c for (matrix) groups only works after Order(g) is called

[dimpase]

Observed behaviour

with a medium-sized matrix group over cyclotomics, and on current master branch:

gap> i:=E(4);;
gap> S:=((1+i)/Sqrt(2))*DiagonalMat([i,i,1,1]);;
gap> T:=((1+i)/2)*[[-i,0,0,i],[0,1,1,0],[1,0,0,1],[0,-i,i,0]];;
gap> g:=Group(S,T);;
gap> c:=Center(g);
<matrix group with 2 generators>
gap> g/c;
Error, I don't know how to find a natural homomorphism for <N> in <G> at /home/dima/Gap/dev/src/lib/factgrp.gi:1408 called from
oper( Parent( D ), D ) at /home/dima/Gap/dev/src/lib/domain.gd:449 called from
attr( sub ) at /home/dima/Gap/dev/src/lib/domain.gd:437 called from
NaturalHomomorphismByNormalSubgroupNCOrig( G, N ) at /home/dima/Gap/dev/src/lib/ghom.gd:340 called from
NaturalHomomorphismByNormalSubgroupNC( G, N ) at /home/dima/Gap/dev/src/lib/grp.gi:2545 called from
FactorGroupNC( G, N ) at /home/dima/Gap/dev/src/lib/grp.gi:2538 called from
...  at *stdin*:8
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 
gap> Order(g);
46080
gap> g/c;
<permutation group with 2 generators>

Expected behaviour

g/c works without calling Order(g) first.

Copy and paste GAP banner (to tell us about your setup)

 ┌───────┐   GAP 4.10dev-1524-gd7b1f30 of today
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-pc-linux-gnu-default64-kv6
 Configuration:  gmp 6.1.2, GASMAN, readline
 Loading the library and packages ...
 Packages:   AClib 1.3, Alnuth 3.1.0, AtlasRep 1.5.1, AutoDoc 2018.02.14, AutPGrp 1.10, CRISP 1.4.4, Cryst 4.1.17, CrystCat 1.1.8, 
             CTblLib 1.2.2, FactInt 1.6.2, FGA 1.4.0, GAPDoc 1.6.1, IRREDSOL 1.4, LAGUNA 3.9.0, Polenta 1.3.8, Polycyclic 2.14, 
             PrimGrp 3.3.1, RadiRoot 2.8, ResClasses 4.7.1, SmallGrp 1.3, Sophus 1.24, SpinSym 1.5, TomLib 1.2.6, TransGrp 2.0.4, 
             utils 0.58

[kedlaya]

I just stumbled onto this issue myself:

gap> G := Group([[[E(3),0,0],[0,E(3),0],[0,0,E(3)]],[[1,0,0],[0,0,1],[0,1,0]]]);
Group([ [ [ E(3), 0, 0 ], [ 0, E(3), 0 ], [ 0, 0, E(3) ] ],
  [ [ 1, 0, 0 ], [ 0, 0, 1 ], [ 0, 1, 0 ] ] ])
gap> FactorGroup(G,Center(G));
Error, I don't know how to find a natural homomorphism for <N> in <G>

I was inserting NormalSubgroups(G); to finesse this, but Order(G) is much faster.

[markuspf]

To be able to compute this quotient GAP needs to prove that G is finite, because then it can handle G and the quotient by a "nice monomorphism".

One wouldn't want to prove that G is finite at creation time, because it might not be, and there might be no way to prove that, or its very expensive to prove what size G is either way, and the quotient might yet be finite and sensibly computable.)

So the only option would be to do this when forming the quotient, and the question is then whether we should pretend to know what we're doing and try computing some representation for G that allows the quotient to be computed (at the danger of this being slow or not terminating) or rely on the user to give the appropriate hint.

A more radical approach would be to form the quotient abstractly (and lazily) and wait for the user to do some computation with it before we are faced with a similar decision.

[hulpke]

The problem is a bit more subtle, and affects a lot of operations for matrix groups -- in some way it is lucky that Centre worked:

If the matrix group is known to be finite, all work is delegated immediately to an isomorphic permutation group. If not, the code later finds out it should know that the group is finite, but is past the delegation phase. So a special treatment is needed.

(The test for finiteness of matrix groups is not horrendously expensive in this context, and in fact the calculation that would follow would be more expensive than the finiteness test, so no harm is done.)

[dimpase]

Is there a way to tell GAP that a matrix group is finite?

[hulpke]

@dimpase
Yes, SetIsFinite.

[dimpase]

So with this toggled, such an error won’t arise? (away from a computer, can’t check). If so, perhaps at least the error message ought to suggest this...