The abelian group class needs to be rewritten. The basic idea was to try to use GAP as much as possible and use Python/Sage to parse input and output. For various technical reasons, that did not work as nicely as hoped. The correct solution, may be to rewrite it from scratch completely separate from GAP.
This doesn't answer your question, but I hope gives you confidence that if you think that something is odd about the implementation and you want to change it, then you are probably correct. On Sat, Oct 3, 2009 at 3:43 PM, Rob Beezer <goo...@beezer.cotse.net> wrote: > > The AbelianGroup class has an extremely welcome method that > manufactures all subgroups of a finite abelian group. These groups > are a big part of an introductory group theory course, so to be able > to list and inspect all subgroups is a really great feature that I > wish was more widespread. However, I've stumbled across the following > behavior (demonstrated here in Z/2Z x Z/4Z), which I think will be > very confusing to students, since it gave me pause: > > sage: G=AbelianGroup([2,4]) > sage: K=G.subgroups()[1] > sage: K > > Multiplicative Abelian Group isomorphic to C2 x C2, > which is the subgroup of Multiplicative Abelian Group > isomorphic to C2 x C4 generated by [f1^2, f0] > > sage: K.gens() > [f1^2, f0] > sage: K.list() > [1, f1, f0, f0*f1] > > At first glance it looks like the generator f1^2 is not an element of > the subgroup! The explanation is that the generators are reported in > terms of the two generators of the full Z/2Z x Z/4Z group G (f0, f1), > while the elements of the subgroup K are reported using conceptually > "new" names for its two generators. In effect there are assignments > f1 = f1^2, f0 = f0 in moving to the elements of the subgroup. Other > examples with smaller subgroups of larger groups can get more > complicated, where the indexing also seems to "shift" downward for the > subgroup. > > So subgroups are being reported as isomorphic copies rather than as > subsets of the group, while retaining enough information to > reconstruct them as subsets. This certainly makes great sense for a > compact manageable internal representation, but does it make sense to > report elements of the subgroup relative to the isomorphic > representation or in terms of the full (ambient) group? > > Seemingly related to this, subgroups are implemented with their own > class, which does not seem to permit always obtaining subgroups of > subgroups - there appears to be something like a check that the set of > names used are equal, which raises an error since they can be more > mismatched than in the above example. In the definition of K above, > switch the index to 5 and ask for K's subgroups to see this error > behavior. At a minimum this would seem to be a bug, because this > action seems to work correctly for the original K. > > I'm building a class for the group of units mod n, mostly on top of > this AbelianGroup implementation. So far, I just represent subgroups > with the same class that I use for the "full" group. Would this be a > bad idea for the AbelianGroup class (or is it a bad idea for the class > I'm building)? Or would there be a way to (optionally) have a > subgroup report its elements in terms of the full group? I don't see > a command to realize a subgroup as a subset of the original group, but > maybe the reverse would make sense: you get a subgroup that is a > subset, unless you ask explicitly for an isomorphic version? Is the > current, or the suggested, behavior totally inconsistent with what is > done elsewhere in Sage? > > Clarifications, unexplored commands, workarounds, policies, > suggestions, opinions, sympathy all welcome. Thanks. > > 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 -~----------~----~----~----~------~----~------~--~---
