Opened 10 years ago
Closed 9 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 )
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:
Attachments (4)
Change History (23)
Changed 10 years ago by
comment:1 Changed 10 years ago by
- Status changed from new to needs_review
comment:2 Changed 10 years ago by
- Cc ncohen added
comment:3 Changed 10 years ago by
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 10 years ago by
Ahem.. "SymmetricGroup?". Sorry :-)
comment:5 Changed 10 years ago by
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 10 years ago by
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 10 years ago by
comment:7 Changed 10 years ago by
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: ↓ 9 Changed 10 years ago by
- Cc jlopez added
In the documentation, replace (several times)
Object collecting examples of graphs
by
Object collecting examples of gropus
comment:9 in reply to: ↑ 8 Changed 10 years ago by
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 10 years ago by
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 10 years ago by
comment:11 Changed 10 years ago by
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.
- 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.
- Settled on not using "Group" in the titles, it feels redundant and I have the same sentiment as Nathann about the graphs object.
- Added a "graphs.sporadic" object which could house the 26 sporadic groups. I've used their common names as used in the classification results.
- 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...).
- 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.
- 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 9 years ago by
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 9 years ago by
Valuable discussion for re-working this on sage-devel (thanks, Nils).
https://groups.google.com/d/topic/sage-devel/B28yuvAlo3A/discussion
Changed 9 years ago by
comment:14 Changed 9 years ago by
- 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 9 years ago by
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 9 years ago by
- 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 9 years ago by
Wouhouuuuuuuuuuuuuuuuu !! :-)
Nathann
comment:18 Changed 9 years ago by
- Milestone changed from sage-5.6 to sage-5.7
comment:19 Changed 9 years ago by
- Merged in set to sage-5.7.beta1
- Resolution set to fixed
- Status changed from positive_review to closed
(EXCELLENT IDEA !)
:-)