\in fails for some elements of an orbit

[james-d-mitchell]

When I do the following:

gap> S := Semigroup(PartialPerm([]));
<trivial partial perm group on 0 pts with 0 generators>
gap> o := Orb(GeneratorsOfSemigroup(S), [1], OnSets);
<open orbit, 1 points>
gap> Enumerate(o);
<closed orbit, 2 points>
gap> AsList(o);
[ [ 1 ], [  ] ]
gap> [] in o;
false

The problem is that the family of [] and the elements family of o are incompatible (since o is a collection of collections of cyclotomics) and [] is in ListsFamily. So, the \in method for IsObject, IsOrbit and IsHashOrbitRep and IsDenseList which should be applied is not, since:

#I  Method 2: ``in: for wrong family relation'', value: 1*SUM_FLAGS+2

I don't really know how to resolve this. This came up in Issue 116 in the Semigroups package. I have resolved that issue by doing HTValue(o!.ht, x) <> fail instead of x in o in the code, but I think the above should not occur.

[fingolfin]

Actually that AsList triggers a segfault for me - sometimes only after repeating it, but still... That worries me much more...

[james-d-mitchell]

Hmm, this is probably caused by the function OnSetsPPerm in the pperm.c file in the GAP source not handling empty sets properly. There is even a comment (which I wrote) in the code starting at line 5402 of pperm.c to that effect. If you insert the lines:

  if (len == 0) { 
    RetypeBag(res, IS_MUTABLE_PLIST(set)?T_PLIST_EMPTY:T_PLIST_EMPTY+IMMUTABLE);
    return res;
 }

in pperm.c starting at line 5406, does the seg fault go away?

Also is one potential fix to simply add a method for testing if an object belongs to an orbit and incrementing the rank by at least SUM_FLAGS + 2?

[fingolfin]

Yes, that change fixed the issue -- and the crash is still present, as the fix for it apparently only was applied to HPC-GAP?

[fingolfin]

The problem here is that the orbit receives the filter IsCollection. The definition of a collection in GAP is this: "A collection in GAP consists of elements in the same family". So one point of view is to say that it is a bug that orb declares the orbit to be a collection in this case.

Another point of view would be to say that GAP should treat empty PLISTs as members of any family (but that might have other terrible consequences)

That makes me wonder: I could in principle define a transitive action of, say, a cyclic group of order 3, on the set [ 17, GF(7), FreeGroup(2) ]. The resulting orbit is not a collection. So perhaps orb should check for that situation?

Or perhaps the definition of an action should be redefined, to clearly state that actions must not yield elements in different families? Hrm...

[fingolfin]

Fixed in 18338c8