Opened 7 years ago

Closed 7 years ago

#13115 closed enhancement (fixed)

"groups" object for organizing examples of groups

Reported by: rbeezer Owned by: joyner
Priority: minor Milestone: sage-5.7
Component: group theory Keywords:
Cc: khalasz, ncohen, jlopez, sjg10 Merged in: sage-5.7.beta1
Authors: Rob Beezer Reviewers: Nathann Cohen, Nicolas Borie
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by rbeezer)

This patch begins the process of creating a convenient place to locate examples of groups, much as is the case for graphs, digraphs and posets.

It creates an object and populates it with methods that return groups. For general families, it just employs the class where the group is implemented, such as for the Mathieu groups. For more specific (simple) examples, the group may be implemented in the method, such as for the quaternion group expressed as a matrix group.

Naming decisions were made to maximize the effectiveness of tab-completion. Once the infrastructure is in place I will work to add every possible example implemented in Sage.

Apply:

  1. trac_13115-groups-object-v4.patch

Attachments (4)

trac_13115-groups-object.patch (6.8 KB) - added by rbeezer 7 years ago.
trac_13115-groups-object-v2.patch (25.8 KB) - added by rbeezer 7 years ago.
trac_13115-groups-object-v3.patch (39.4 KB) - added by rbeezer 7 years ago.
trac_13115-groups-object-v4.patch (26.8 KB) - added by rbeezer 7 years ago.

Download all attachments as: .zip

Change History (23)

Changed 7 years ago by rbeezer

comment:1 Changed 7 years ago by rbeezer

  • Authors set to Rob Beezer
  • Status changed from new to needs_review

comment:2 Changed 7 years ago by ncohen

  • Cc ncohen added

(EXCELLENT IDEA !) :-)

comment:3 Changed 7 years ago by ncohen

Hellooooooo !!!

I just read the patch and I wondered about the mistakes we did with the list of graph generators... Namely that the graph generators are all named SomethingGraph?, SomethingElseGraph?, etc, etc... (see the doc http://www.sagemath.org/doc/reference/sage/graphs/graph_generators.html)

I recently grew *very* bored with having to add Graph at the end of the names every second second (it can be said, can't it ? O_o). It really encodes nothing useful, considering that all our methods are accesses through graphs.Something or imported through the graph_generators module. Hence, as it seems to be even worse in your case ( CyclicGroupPermutationGroup?, MathieuPermutationGroup? ), my opinion on the subject is that the best would definitely be to have constructors named Cyclic, Mathieu, Symmetric, Quaternion, ...

Of course, I understand that you may have groups returned in different representations, and that is a very good thing. What about solving this problem with an optional argument ? Something like Mathieu(permutation_group = True) ?

There your situation is more complicated than ours. It's totally up to you : I use groups very rarely and there are probably thousands of use case I do not imagine... But I would gladly remove the Graph at the end of our constructors on the first occasion :-)

Oh, and by the way...Could you please add a PermutationGroup? constructor too ? :-)

THaaaaaaaaaaaaaaaaanks !!

Nathann

comment:4 Changed 7 years ago by ncohen

Ahem.. "SymmetricGroup?". Sorry :-)

comment:5 Changed 7 years ago by rbeezer

Dear Nathann,

Thank-you for your comments. I was hoping a small-ish patch would provoke some suggestions before I went further.

I think I agree with you entirely about not having "Group" at the end. I have had the same thought about graphs, as you have mentioned. But with tab-completion you don't need to type it. I'll likely remove "Group" from the method names.

I thought of having representations as a keyword. But then you have to remember it, and type it.

graphs.Cyclic(representation='permutation')

I think that is worse, as in "more typing" and "more remembering."

Thanks, Rob

comment:6 Changed 7 years ago by ncohen

Helloooooooo !!

Well, you would only have to add this keyword when you do NOT want to use the default constructor, which may very well be the permtutation group one :-)

But of course if you always work with matrix groups that would mean adding as_matrix_group=True all the time to constructors, and that really is a hassle. Hence I totally agree :-)

Nathann

Changed 7 years ago by rbeezer

comment:7 Changed 7 years ago by rbeezer

Added v2 patch, mostly for safe-keeping. Making progress and comments are welcome.

May add

groups.sporadic.xxxxx

as a home for the sporadic simple groups.

comment:8 follow-up: Changed 7 years ago by jlopez

  • Cc jlopez added

In the documentation, replace (several times)

Object collecting examples of graphs

by

Object collecting examples of groups
Last edited 7 years ago by jlopez (previous) (diff)

comment:9 in reply to: ↑ 8 Changed 7 years ago by rbeezer

Replying to jlopez:

In the documentation, replace (several times)

Thanks! I keep doing that, since I have graphs<dot> as my mental model. ;-)

comment:10 Changed 7 years ago by kcrisman

Just pointing out that this would have been really useful today in the PREP workshop.

And I disagree about the whole "don't add Group all the time" thing, but since I probably won't review this (though I'll use it), maybe this doesn't count.

Changed 7 years ago by rbeezer

comment:11 Changed 7 years ago by rbeezer

v3 patch is still in-progress, though I am not sure if I'll go for an exhaustive list before marking this "needs review." Please comment before I get carried away and do a lot of repetitive stuff that needs to be reworked.

  1. This is really more of a documentation and organization improvement, mostly targeting folks (students) who are not group theory experts. So there are some illustrative doctests, but for established groups things like doctesting error messages are left for the originating class.
  2. Settled on not using "Group" in the titles, it feels redundant and I have the same sentiment as Nathann about the graphs object.
  3. Added a "graphs.sporadic" object which could house the 26 sporadic groups. I've used their common names as used in the classification results.
  4. One sporadic group (Higman-Sims) is built as subgroup of an automorphism group of a graph. Not sure how many more of these could be done this way (or on designs, or...).
  5. Two sporadic groups done by grabbing generators from the ATLAS. I'll check about permission before going too far down this path (yes, the optional AtlasRep package will do this, but requires network access - I want this to be easy for the neophyte). Current approach is not sustainable for the larger groups, and unknown it appears for the Monster. I'd stick to the smaller ones. For example, Co1 seems to take several minutes to create using this approach.
  6. Partially implemented a keyword for alternate representations of the sporadic groups. Likely will flesh that out, but do not plan to provide the actual alternates.

Passes tests, but not ready yet for review. I am interested in huge blunders, strong opinions, and input from potential reviewers.

Thanks, Rob

comment:12 Changed 7 years ago by rbeezer

For the record, email from R.A. Wilson, main contact for the Atlas project:

Given that the Atlas data is available in both
GAP and MAGMA, it would be inconsistent of me
not to allow Sage the same access. GPL seems
to describe fairly well how GAP treats
the data, so that seems fair enough too.
I guess it would be sensible for me to put an
explicit statement on the Atlas webpage that
it can be used under the terms of the GPL.

So you can take it that the Atlas data is licensed
under GPL v2+, and in particular it comes without
warranty of any kind. There are known errors in
the data, including what appears to be a systemic
error in computing the GAP version of permutation
representations from the `Meataxe' version (which
is the master version). (AtlasRep does not use
the GAP version, despite being in GAP!) So I'd
recommend either using what you get out of AtlasRep,
or working directly with the master version (which
consists of a header line followed by the permutation
in image format). An overall sanity check on each
group is probably a good idea too!

Best wishes,

Rob Wilson.

comment:13 Changed 7 years ago by rbeezer

Valuable discussion for re-working this on sage-devel (thanks, Nils).

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

Changed 7 years ago by rbeezer

comment:14 Changed 7 years ago by rbeezer

  • Cc sjg10 added
  • Description modified (diff)

Substantially reworked now with modules and imports doing all the work. Top-level "groups.<tab>" object with primary divisions by implementation (such as groups.permutation.<tab>).

Previous patch has lots of documentation that could go to help some of these files, it needs it. On another patch, later.

Previous patch had an initial foray into manufacturing some sporadic simple groups. On another patch, later.

v4 patch is ready for review now.

comment:15 Changed 7 years ago by ncohen

Well, I think that this patch is good to go, but I do not really feel entitled to give a positive review to a patch in this section, considering what I know about groups... Could somebody here give it a look ? That will be good to have in Sage :-)

Nathann

Apply trac_13115-groups-object-v4.patch

comment:16 Changed 7 years ago by nborie

  • Reviewers set to Nathann Cohen, Nicolas Borie
  • Status changed from needs_review to positive_review

It is also ok for me...

That's really constitute nice entrances points to play with groups in Sage.

Apply trac_13115-groups-object-v4.patch

comment:17 Changed 7 years ago by ncohen

Wouhouuuuuuuuuuuuuuuuu !! :-)

Nathann

comment:18 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.6 to sage-5.7

comment:19 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.7.beta1
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.