New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abelian groups #9773
Comments
Attachment: trac_9773-abelian-groups-draft-1.patch.gz |
Author: Rob Beezer |
comment:1
AAG is the class of additive abelian groups. This is an infinite group with a subgroup and a quotient. (Typically quotients lose the generators and are "generic" but not in this example.)
GUN is a constructor of Groups of Units Mod n. It employs MAG, the class of multiplicative abelian groups. This is an intersection of two subgroups, and then a Cayley table is free (in the category of multiplicative groups).
This is an example from the current additive abelian wrapper class. It shows the generators keyword allowing arbitrary elements to form the group, so long as they know how to add. GUN above is similar, but with multiplication.
There is lots to do here still: different filenames, different class names, error-checking, doctests, comparisons, and so on. But the code seems to be working. I'm not 100% confident on the |
comment:2
Will this interact at all with the class Also, how do you define R or Q as additive abelian groups with this setup? |
comment:3
Replying to @jhpalmieri: Hi John, Thanks for the good questions. I began this when I tried to implement a multiplicative group in concert with the work at #6449. So I really didn't even have groups like R and Q in mind. Truth-in-advertising would suggest I sprinkle in some "finitely generated" qualifiers in class names and filenames. I've plugged this into the categories framework as groups, but hadn't thought about modules. I'll go take a look at all that to see how this might fit in. Maybe Nicolas Thiery will have some ideas as well. Thanks again, |
comment:5
Replying to @jhpalmieri:
I looked at these two classes. Generally they seem to require the same ring in each "component", whereas the FGP_Module class allows for diffferent rings in each component, such as in creating something like Z_3 x Z_4. So I don't see an abvious way to leverage these, but maybe I'm missing something. Rob |
comment:6
To the release managerPlease close #9694 when this ticket is merged. |
Attachment: trac_9773-abelian-groups-draft-2.patch.gz |
comment:7
Code is stablizing in draft 2 patch, and I'm starting to write the doctests. Still uncertain about There are liberal comments in the code and the |
comment:8
Question: does this patch solve #10181? Paul Zimmermann |
comment:9
Replying to @zimmermann6:
While we're at it, how about #9940? |
comment:10
Replying to @zimmermann6:
Short answer: this could speed up Full details at #10181. Thanks for asking. Rob |
comment:11
Replying to @jhpalmieri:
This patch has code that is in pretty good shape (IMHO). It still needs doctests, plus things like an equality method. So it could fix #9440 if the equality method is done right? |
comment:12
Justin - no documentation to speak of, but look at the derived classes to get a feel for how this might work. Any insights or ideas you might have would be helpful before I try to finish this off later this spring. Rob |
comment:13
Attachment: trac_9773-abelian-groups-draft-3.patch.gz Draft 3 patch is actually about a year old at time of posting (for safe-keeping). Category code changed out from under me, so I had to start over last summer. This applies on 5.0.rc0, builds, and simple testing of the abstract classes seems to be successful. Needs documentation, some changes, and practical derived classes, like totally abstract cyclic groups, the multiplicative subgroup of units mod n, etc. IIRC, there are examples of these in the previous drafts. I fully intend to work on this over the summer. |
comment:14
I keep plugging away at this. Some improvement by exploiting category code. Totally reworked, so most of my comments above are obsolete. Draft 4 patch is very functional, with the following caveats that I cannot figure out. Assistance greatly appreciated if you can provide advice or specific pointers. There is quite a bit of functionality demonstrated in the module-level doctests. Little or no error-checking yet.
I've tried to add copious comments to make it easier to navigate the code. More specific problem areas are flagged with |
Attachment: trac_9773-abelian-groups-draft-4.patch.gz |
comment:15
Just replaced the patch. Realized the Test suite on the elliptic curve example was testing the wrong instance - as corrected one test fails, so it is commented out, but should be experimented with to determine root cause. |
Attachment: trac_9773-abelian-groups-draft-5.patch.gz |
comment:16
draft-4 failed to include "init.py" in the patch - that has been corrected in draft-5. David Roe helped me rework the initialization of the module class, so now the test suite is not doing additive tests on the multiplicative classes. And I also believe I understand the problems with the element constructor (again with David's help). So I think I'm over the hump on this one now. Long list of tests at module level are all passing, except one test suite (which I think I understand and can correct). A few other test suites commented-out, but I think they are correctable also. |
Attachment: trac_9773-abelian-groups-draft-6.patch.gz |
comment:17
draft-6 patch is darn close to functional. Lots of doctests, all passing. Lots of code pushed up to abstract class. Much more to do on docstrings. One real edit in |
comment:18
Hi Rob, Just a quick note to say that I've played with draft-6 a bit (mainly with the |
comment:19
Replying to @aghitza:
Thanks very much, Alex, for the encouragement. Still lots of docstrings to work on, but making (slow) progress, since classes started recently. Soon. ;-) |
comment:20
any progress on this? Which info is needed? Paul |
comment:22
Update: v6 patch will compain about one hunk not applying - just ignore it, it is no longer needed. On 5.12: compiles and passes all tests. Basically I think the code is solid on this one, but it needs extensive work to fully document and doctest. And then it would be a big effort to slowly integrate in. |
comment:26
Hey Rob, what's the status here? If one (say, me) were to have a student who knows some algebra and is a solid programmer, could they finish up what is remaining? Could be really useful stuff. |
comment:27
Replying to @kcrisman:
I am also interested in this. I am a student as well with algebra coursework under my belt. If there is still a need for this and you would like to work together, I am down. |
This patch will implement abelian groups, both additive and multiplicative, finite and infinite, under a common abstract class, using machinery for quotients of modules over
ZZ
. This will make subgroups, intersections of subgroups, isomorphism classes, and quotient groups possible. Generators may be of any type, so long as they support the minimal operations required.CC: @loefflerd @JohnCremona @williamstein @nthiery @boothby @jasongrout @kcrisman @mwhansen @RalphieBoy @aghitza
Component: algebra
Author: Rob Beezer
Issue created by migration from https://trac.sagemath.org/ticket/9773
The text was updated successfully, but these errors were encountered: