Hm, wouldn't this just be a direct product of the individual group actions? It seems to me that we're expecting the permutations to act according to an 'obvious' group action. Should we also expect 'obvious' actions of things like a dihedral group when given a 2-dimensional vector? Probably the answer is to generalize and build up a proper group actions category (with obvious methods passing to representations!).
It looks like there's a bare semblance of a glimmer of the idea of actions in Sage: http://combinat.sagemath.org/doc/reference/categories/sage/categories/action.html but it's not very fleshed out.... One way to deal with the problem at hand would be to define a direct product of group actions and behave/coerce accordingly. This could look something like: 1) Look at the list of things the permutation is supposed to be acting on, like [1, Set([1,2])] 2) Build a group action parent for each of the components, which we then use to build a direct product parent 3) Return the appropriate element of the direct product. Such a framework would have the advantage of being there to deal with similar problems in other groups. cheers! On Friday, March 22, 2013 4:43:18 PM UTC+3, Volker Braun wrote: > > I think its unambiguous to define the orbit of x recursively as > 1. use the action on domain elements if x is a domain element > 2. otherwise, assume that the x is a list/set/... of domain elements > > > > On Thursday, March 21, 2013 3:10:38 PM UTC+1, Dima Pasechnik wrote: >> >> While working on http://trac.sagemath.org/sage_trac/ticket/14291, it >> came to my attention that one can now have permutation groups acting >> on quite arbitrary domains (the only requirement for the domain elements >> seems to be them being hashable). >> >> This leads to the following kind of confusing situations: >> suppose our permutation group G acts on, say, (1,2,3,4,(1,2),(2,3)). >> Then things like "the orbit (1,2) under G" can be interpreted in two >> different incompatible ways: >> * the images under G of the pair of domain elements 1 and 2. >> * the images under G of of the domain element (1,2). >> >> I can see two ways to remedy this: >> 1) a framework with parents, etc >> 2) "boxing" the most "primitive" elements of the domain, i.e. >> as in our example, using ((1),(2),(3),(4),(1,2),(2,3)) instead of >> (1,2,3,4,(1,2),(2,3)); then certainly ((1),(2)) and (1,2) are >> different things, problem solved. >> >> (and certainly you can tell me that actually it's OK as it is... :)) >> >> IMHO, 2) is relatively easy to put into place, and 1) is tricky and quite >> a bit of >> work. >> >> Dima >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
