Stabilizers of permutation groups, and most likely some other subgroups of permutation groups, do not know much about their ancestry. In the example below, all the elements of the stabilizer fix 4 by definition, and so the stabilizer considers itself a subgroup of the symmetric group on 3 symbols, as seen when it reports its degree to be 3. But then the calculation of the orbits "leaves out" the singleton orbit [4] that I would have expected to see in this scenario.
sage: D = DihedralGroup(4) sage: S = D.stabilizer(4) sage: S.degree() 3 sage: sage: S.orbits() [[1, 3], [2]] Some permutation groups carry an attribute "_deg", but if it is not set, then it is inferred as the "largest moved point." This is the mechanism that explains why 4 gets bypassed above. It seems that GAP never gets too concerned about this notion of the degree of a permutation group, and the GAP command computing the orbit allows one to explicitly provide the set of points. But as called from Sage, there is no information in the stabilizer about where it came from, so simply a best guess for degree gets passed along to GAP. I can fix the stabilizer, but I am wondering if something more systematic is called for - consistently setting _deg in subgroup creation, or earlier in general group creation, and with less reliance on the largest moved point as a best guess. As this is perhaps different from the GAP philosophy (which I do not claim to know well) maybe there is a good reason for not being so careful? Maybe there are times when it is important to scrunch down the degree as happened above? Thoughts? Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
