Yes, I see now that the main problem is that AddSet calls IsSet rather
than it spends lots of time for actual rewriting of the set.
However, looking at IsSet, one sees that first of all it tests
whether it is already known that the argument is a set by checking
certain flag in its record. In the best of my knowledge,
it is really fast providing this flag is set to `yes`.
Note that the sets in question are generated as the images of the
original set S. The image of S is a set, so the corresponding
function which computes the image of a set under a permutation (see the
module permutat.c) should set , I believe, the abovementioned flag to `yes`.
(In other words there might be a bug)
Otherwise I fail to understand why
the removal of the call to IsSet can improve performance of
Orbit(,,OnSets) so dramatically.
Is this a set of numbers, or a set of (for example) vectors?
It makes a difference, for the reason that Frank was talking about
before, namely that a vector in the set might be altered (by
assigning to one of its entries). A set of vectors can thus NOT be
guaranteed to stay sorted, even if no changes are made to the set
itself, only changes to the elements.
It seems still unclear. If g is a permutation of a set X of whatever nature,
S a subset of X, then S^g is a set, otherwise one would expect a message
like "Error, <set> must be a set in ...OnSets".
That is, S^g is uniquely defined. That is , S^g should be a set, so
the appropriate flag of it is 'yes'.
Certainly I agree that there are operations which can disrupt the order of
S, say as it was pointed out by making changes to elements,
but S^g should be exempt from this list.
Dept. of Mathematics,
Univ. of Western Australia, Nedlands WA 6009, Australia