Consider the following discovered in the course of debugging an IRC
query:
sage: G=SymmetricGroup(4)
sage: g=G("(1,2)")
sage: g in G.centralizer(g)
True
sage: G=SymmetricGroup(3)
sage: g=G("(1,2)")
sage: g in G.centralizer(g)
False
Explanation:
In the first case, (3,4) is in the centralizer and so
G.centralizer(g).degree() == 4.
In the second case, the centralizer is just {(), (1,2)} and so
G.centralizer(g).degree() == 2.
A workaround is g in G.centralizer(g).list() which seems to be
immune to this.
It looks like G.centralizer(g) gets generators from GAP and uses
those to build a new permutation group, independent of any notion of
where g came from (ie degree of its parent).
I imagine I can fix this one, but I'm posting here since I wonder if
this is a concrete example that ties into the current discussion about
symbols, fixed/unfixed elements, transitivity, etc for permutation
groups?
http://groups.google.com/group/sage-devel/browse_thread/thread/330ddca4c6ea06ca
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
