groups<dot>

90 views
Skip to first unread message

Rob Beezer

unread,
Jun 11, 2012, 5:51:37 PM6/11/12
to sage-...@googlegroups.com
We have objects which conveniently organise examples of certain (named) mathematical objects, such as graphs<dot>, digraphs<dot> and posets<dot> (and others?).   These also help keep the global namespace a little cleaner.  I'd like to do the same thing with groups.

Comments are welcome as I work on this through the week at Sage Days.  Right now I'm wondering how best to handle multiple representations of the same group.  For example, the quaternion group of order 8 is implemented now as a permutation group, and can also be represented as a groups of matrices of size 2 over the complexes or over GF(3).

Would you like to see

groups.QuaternionPermutationGroup()
groups.QuaternionMatrixGroupComplex()
groups.QuaternionMatrixGroupGF3()

or would you just like

groups.QuaternionGroup()

and then use keywords to get the different representations?  And if so, which keywords?  (representation='permutation'|'matrix'|'presentation', field='complex'|'GF(3)', degree= , etc)  I'd expect for some groups, the choice of a default representation could be a matter of personal preference.  It'd be nice if there was an obvious default with no keywords and perhaps annoying if you always had to supply keywords.  Which is making me lean to the first suggestion above, even if it seems rather verbose.  with tab-completion it might work nicely (and we don't have anyway to do tab-completion on keywords right now).

Thanks,
Rob


Rob Beezer

unread,
Jul 26, 2012, 11:32:42 PM7/26/12
to sage-...@googlegroups.com
On Monday, June 11, 2012 2:51:37 PM UTC-7, Rob Beezer wrote:
We have objects which conveniently organise examples of certain (named) mathematical objects, such as graphs<dot>, digraphs<dot> and posets<dot> (and others?).   These also help keep the global namespace a little cleaner.  I'd like to do the same thing with groups.

A patch with substantial progress is at:

http://trac.sagemath.org/sage_trac/ticket/13115

along with some guidance on my thinking along the way.  This is not quite ready for review, but has passing doctests, good documentation, etc.  If you want to shape the final product, now would be a good time to comment before I do some more (repetitive) work in the same mold.

Thanks,
Rob

William Stein

unread,
Jul 26, 2012, 11:36:42 PM7/26/12
to sage-...@googlegroups.com
I'm really glad you're doing this. During my course for high school
kids today [1], they asked "what can Sage do with groups", and I was
disappointed with "groups.[tab]" in sage-5.2. I'm really happy you're
improving this.

[1] https://github.com/williamstein/simuw12

William

>
> Thanks,
> Rob
>
> --
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
>
>



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Rob Beezer

unread,
Jul 27, 2012, 2:03:49 PM7/27/12
to sage-...@googlegroups.com
Thanks, William, for the interest. 

Course looks like fun.  Patch is in good enough shape that you could show it to the students as an example of Sage's evolution.  Or an example of having your wishes granted.  ;-)

Rob

Rob Beezer

unread,
Aug 14, 2012, 7:43:59 PM8/14/12
to sage-...@googlegroups.com
This patch is now ready for review.  I've taken inspiration from the recent discussion about factory functions for Fano polytopes [1], and achieved the  groups.<tab>  effect with a sequence of  "import foo as bar"  commands as a new view of on top of the existing organization of the code for groups.  It goes two-deep, so for example, you will go  groups.matrix.<tab>  to see all the matrix groups.

In light of all the discussion about startup time and importing modules [2], I'm wondering if this is an improvement on the current situation of importing various groups individually into the global namespace.  Certainly it is worse now, since I have just added on and not removed anything.  But if starting from scratch, or deprecating old imports, is the approach I've taken better?  If so, it could be a model for changes elsewhere (posets, designs, graphs).

If somebody knowledgeable wanted to comment on the question of import efficiency, that would be very helpful long-term.  (Which is not necessarily a request for a full review of the whole ticket.)

Thanks,
Rob

[1]  https://groups.google.com/d/topic/sage-devel/B28yuvAlo3A/discussion

{2]  https://groups.google.com/d/topic/sage-devel/pqpDrJw1AnA/discussion


Reply all
Reply to author
Forward
0 new messages