"groups" object for organizing examples of groups

[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​

[ncohen]

(EXCELLENT IDEA !) :-)

[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

[ncohen]

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

[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

[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

[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.

[jlopez]

In the documentation, replace (several times)

Object collecting examples of graphs

by

Object collecting examples of groups

[rbeezer]

Replying to jlopez:

In the documentation, replace (several times)

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

[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.

[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

[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.

[rbeezer]

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

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

[rbeezer]

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.

[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

[nborie]

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

[ncohen]

Wouhouuuuuuuuuuuuuuuuu !! :-)

Nathann