On May 30, 2010, at 4:46 PM, Rob Beezer wrote:
On May 30, 2:46 pm, Mike Hansen <[email protected]> wrote:
I've been working on this over the next few days, cleaning up the
code, and making permutation groups act over an "arbitrary" domain.
I'll be posting these in the next few days.
Mike H - thanks for your work on this!
Mike O'S - that's a great wish list. I'd like to see lots of that
happen. Another item on my wish list is to build a quotient group and
have its elements (optionally) actually be cosets. Right now for
permutation groups you get back a new permutation group:
sage: D=DihedralGroup(7)
sage: H=D.subgroup([D((1,2,3,4,5,6,7))])
sage: Q=D.quotient(H)
sage: Q.list()
[(), (1,2)]
Maybe with a new "coset" class and Mike's arbitrary domains this would
be easy to implement?
I've brought this one up before. How do folks feel about having the
named permutation groups available like graphs are? In other words,
rather than each family of permutation groups being a new class, there
is a single system-wide object ("groups", or "perm_groups") whose
methods produce instances of permutation groups (or more generally,
just groups). So for example,
D=groups.DihedralGroup(7)
would replace the above syntax. Advantages - namespace is less
cluttered, and tab-completion (groups.<tab>) gives precise one-stop
shopping for examples of specific groups.
I'm +1 to a group object like this, but removing things from the top
level namespace is backwards incompatable and could break a lot of
code out there. As for classes vs. methods, one advantage of classes
is that sometimes certain methods can be simplified/optimized if you
know what specific group you have.
- Robert
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
