Again apologies for a crippled mail. I'm learning the subtleties of the
Internet mail protocol the hard way.
[both erraneous mails have been removed from the archive. AH]

Dear GAP-Forum,

I have been asked to respond to the mails by Mathias Kratzer, Frank L"ubeck
and Andrea Caranti, concerning ConjugacyClass(<G>,<g>):

Mathias Kratzer observed that the function `ConjugacyClass' does not issue
an error message if the element is not contained in the group, though the
manual states this.

Andrea Caranti already explained why this happens: There is no test
for <g> actually being an element of <G>. (This test has been
forgotten in the dispatcher function `ConjugacyClass'.) As in the general
case, an error is the only sensible response for <g> being not an element of
<G> this is what the manual states.

Frank L"ubeck mentioned already that this extended use can be desirable
at times, for example to represent the action of a subgroup on the elements
of a larger group. Therefore I would consider it rather a feature than a
bug.

>From a theoretical point of view a conjugacy class is simply an orbit of a
group on its elements. Depending on the willingness to bend notation, you
may talk of the classes of a subgroup on a group or even of the classes of a
permutation group on points. Everybody will know what you are talking about.
As an orbit, a class does not behave differently than any other orbit
and therefore the GAP functions for conjugacy classes just use the standard
GAP machinery for orbits of a group (using the '^' action). As the mails of
Frank L"ubeck and Andrea Caranti point out that can have desirable and
amusing effects.
I don't think, however, that this can cause any harm in
that GAP would return wrong results. The most serious problem is
that an algorithm erroneously calls 'ConjugacyClass' not with a group element
but with something else, but you get errors not immediately but only later
(which would make debugging harder). If you suspect that such a thing could
happen, you can simply add an element test before calling `ConjugacyClass'.

The only reason for the command 'ConjugacyClass' being different from
'Orbit' is to permit further improvements that are only possible for elements
of groups, like -- say -- test of cycle structures for permutation groups.
Such further tests may run into errors if objects are not group elements.
In the example of Andrea Caranti, we would get for example:

gap>         S5 := SymmetricGroup (5);
Group( (1,5), (2,5), (3,5), (4,5) )
gap>         c := ConjugacyClass (S5, 1);;
gap> 3 in c;
Error, <obj> must be an element of the parent of <G> in
Centralizer( C.group, C.representative ) called from
<elm> in <rec> called from
main loop

Therefore one should not use 'ConjugacyClass' as an acronym for 'Orbit'.

The method selection in GAP4 (where 'ConjugacyClass' is essentially
implemented as a special 'Orbit') will take care automatically of such problems
in that methods that require -- say -- permutations being called only if the
objects are indeed permutations. To ensure this in GAP3 (not only for
'ConjugacyClasses' but also for other commands) would only be
possible at the expense of many extra `if' statements which neither improve
readability, nor maintainability of the code. Therefore I'm reluctant to
start changing the code, even at the cost of the manual telling occasionally
little lies.

The case of Frank L"ubeck's use is slightly different. It certainly is a
sensible use and should be supported (though at the moment I would not bet
on this fact being supported for all groups. If you want to be on the safe
side use 'Orbit' or 'RepresentativeOperation'.).
This use should be supported in general in GAP4.

Wishing you all a Merry Christmas and a Happy New Year,

Alexander Hulpke