In his reply to our announcement of the new function
'PresentationViaCosetTable' which is available in a file 'pres.g'
via ftp from our 'incoming' directory, Leonard Soicher writes

Before it is returned, the resulting presentation is being simplified
by appropriate calls of the function 'SimplifyPresentation', but without
allowing it to eliminate any generators.

How do you do this? That is exactly what I need.

As described in the manual section 'Tietze Transformations', each
presentation record, 'P' say, carries with it certain parameters,
the so-called 'Tietze options'. One of these is the parameter
'P.generatorsLimit' which by default is initialized to be zero.
Its purpose is to prevent the Tietze transformations functions
from eliminating too many generators.

More precisely: The functions 'SimplifyPresentation', 'TzGo', and
'TzGoGo' are not allowed to eliminate a generator if the resulting
number of generators would be smaller than this bound.

Hence, if you want to apply the function 'SimplifyPresentation'
without generator eliminations, it suffices to set the parameter
'P.generatorsLimit' to a value which is greater than or equal to the
current number of generators before calling the function. (This is
exactly what is done in the function 'PresentationViaCosetTable'.
You will find the corresponding code at the end of file 'pres.g'.)

Remark:

Unfortunately, there is an inconsequence in the current design
of the function 'PresentationFpGroup'. It calls some Tietze
transformations only after initializing the parameter
'P.generatorsLimit' by the default value zero. Hence it sometimes
eliminates some redundant generators. We intend to change this
behaviour in the next release of GAP.

However, the function 'PresentationViaCosetTable' needs already
now such a modified version because it has to guarantee a bijection
between the generators of the given group and those of the resulting
presentation. This is the reason why there is a modified copy of the
function 'PresentationFpGroup' in the file 'pres.g'. (It has been
renamed to 'PresentationFpGroup0' only in order to prevent it from
being overwritten if the library file 'fptietze.g' is read in again
during a GAP session.)

In the file 'pres.g' announced on April 18th, this modified version
was an ad hoc modification which just fulfilled these requirements.
Then, under the aspects of Leonards Soicher's request, I have replaced
it a day later, on April 19th, by another version which is more likely
to become the final one. Hence, if you are interested in this modification
and if you fetched the file 'pres.g' already before that replacement,
you should get a new copy before looking a it. (The performance of the
function 'PresentationViaCosetTable' is not affected by this change.)

Also, the manual says that it may be useful to apply SimplifyPresentation
more than once. What is a good rule of thumb for the number of times to
apply SimplifyPresentation to a presentation? Does this rule change if
no generator is being eliminated at any stage?

This is hard to be answered in general because the behaviour may be
very different for different presentations. A vague step in this
direction is the command 'TzGoGo' which applies the function
'SimplifyPresentation' again and again until there were five successive
calls which did not provide any improvement. In certain applications
this is quite convenient, in others it is nasty. I wonder whether
one should allow the user to specify the number of repetitions without
improvement by an additional, optional argument such that the value
five would just be the default value of that parameter.

Volkmar Felsch, Aachen (volkmar.felsch@math.rwth-aachen.de)