Confusing behaviour in repeated calls of the same code

[ThomasBreuer]

The following happens in the current master branch as well as in GAP 4.11.1.

I execute some code (essentially from a manual example) in a new GAP session.

gap> G:= Group( (1,2,3,4), (1,2) );;                                           
gap> N:= DerivedSubgroup( G );;
gap> F:= FactorGroupNC( G, DerivedSubgroup( G ) );
Group([ f1 ])
gap> HasParent( F );
true
gap> IsIdenticalObj( F, Parent( F ) );
true

When I enter the same lines again in the same session, the result looks different.

gap> G:= Group( (1,2,3,4), (1,2) );;
gap> N:= DerivedSubgroup( G );;
gap> F:= FactorGroupNC( G, DerivedSubgroup( G ) );
<pc group with 1 generators>
gap> HasParent( F );
false

(I observed this difference because it appears as a difference in manual tests after the changes from pull request #4653.)

Does it make sense at all to set F as its own Parent value in the first case? And if yes then why is the parent not set in the second case (and in all subsequent calls during the session)?

[hulpke]

The issue is basically the function FactorGroup and the GAP3-compatibility that one could call NaturalHomomorphism on a FactorGroup and get the homomorphism.

The factor group itself is the same both times -- GAP caches these small cyclic groups (in CYCLICACHE), since they (and associated families) tend to fill up memory in longer calculations otherwise.

But the second time the group needs to be created anew from its generators (at this point parent is not set, thus the discrepancy), so that different data can be stored for NaturalHomomorphism.

My solution would be to remove this compatibility kludge of first creating the factor group and then asking for its NaturalHomomorphism.

[ThomasBreuer]

@hulpke I agree that it is a good idea to get rid of the hack around NaturalHomomorphism and FactorGroup. I hope this functionality is not mentioned in the documentation, and that it is not used in interesting GAP 4 code.

If it is not necessary to create a group anew from the generators of a cached group, this will solve the inconsistency.
However, the question remains why the group stores itself as a parent. What is the benefit of this? My understanding is that one can might get useful information about an object from its stored parent, which is not the case if the object and its parent are identical.
(Note that the actual output that occurs in the manual example in question depends on whether a parent is stored or not.)

[hulpke]

@ThomasBreuer I suspect it is documented, but to my knowledge it has not been used in code (and all examples I'm aware of have emphasized NaturalHomomorphismByNormalSubgroup.

I think the reason for the stored Parent has been that at some point in the past every PC group was supposed to have a Parent so that HomePcgs was well defined. (This ultimately turned out not to solve the problem, and so is gone now).