Nicola Sottocornola wrote:
why if I ask IdGroup(g1) with g1 defined in the following wayf:=FreeGroup("a","b");; g:=f/[f.1^4,f.2^4,(f.1*f.2)^2,(f.1^(-1)*f.2)^2]; g1:=DirectProduct(g,AsGroup([(),(1,2)])); IdGroup(g1);
I obtain this message:
value property is already set the other way at
SetCanEasilyCompareElements( FamilyObj( One( G ) ), true );
Thank you very much for the bug report. This error will be corrected in the
next bugfix or release (whatever comes earlier). Let me know if you need a
temporary patch already now.
(But see also the last paragraph for an easy workaround.)
Since you ask `why', let me sketch what happens:
There is a property `CanEasilyCompareElements' that indicates, whether a
comparison of elements (say of a group) can be done reasonably easy. This
certainly holds for permutations or matrices, but for finitely presented
groups such a test might be very expensive, as one has to compute a faithful
representation or a confluent rewriting system. Therefore this property by
default should return `false' for the (family of) elements of a finitely
Now you do (via IdGroup) some nontrivial calculations with g1 and g. In the
course of this calculation, GAP *must* compare elements and thus computes a
faithful permutation representation for g.
With this information element comparison becomes cheap, and GAP tries to
store this new information. This is where the bug arises, the property was
already set to `false' before and GAP refuses (as a default safety net) to
reset it the other way.
(Thus the bug fix involves some trick to not explicitly store a value
`false' in the first place.)
This explanation indicates an easy workaround (which also might speed up
After defining <g>, enforce computation of a faithful representation.
(GAP would do this anyhow later -- so there is no extra cost. However only
you (but not GAP) knows yet that <g> is very small and this computation will
not be hopeless -- thats why this is not default.)
Now `CanEasilyCompareElements' has a value of `true' and `IdGroup' works fine.
(As GAP also knows that element comparisons in <g> are harmless it will
use them probably earlier -- this is why the calculations might get faster.)
I hope this is of help.
-- Colorado State University, Department of Mathematics,
Weber Building, Fort Collins, CO 80523, USA