Opened 12 years ago
Last modified 8 years ago
#9773 needs_info enhancement
Abelian groups
Reported by:  Rob Beezer  Owned by:  Alex Ghitza 

Priority:  major  Milestone:  sage6.4 
Component:  algebra  Keywords:  
Cc:  David Loeffler, John Cremona, William Stein, Nicolas M. Thiéry, Kelly Boothby, Jason Grout, KarlDieter Crisman, Mike Hansen, Justin Walker, Alex Ghitza  Merged in:  
Authors:  Rob Beezer  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  Commit:  
Dependencies:  Stopgaps: 
Description
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.
Attachments (6)
Change History (33)
Changed 12 years ago by
Attachment:  trac_9773abeliangroupsdraft1.patch added 

comment:1 Changed 12 years ago by
Authors:  → Rob Beezer 

Cc:  David Loeffler John Cremona William Stein Nicolas M. Thiéry Kelly Boothby Jason Grout KarlDieter Crisman added 
Status:  new → needs_info 
Type:  defect → enhancement 
comment:2 followups: 3 5 Changed 12 years ago by
Will this interact at all with the class CombinatorialFreeModule
? I don't know what the long term plans are, or even if there are any, for connecting this with FreeModule
, but the combinatorial version has some nice features.
Also, how do you define R or Q as additive abelian groups with this setup?
comment:3 Changed 12 years ago by
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. Truthinadvertising 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, Rob
comment:4 Changed 12 years ago by
Cc:  Mike Hansen added 

comment:5 Changed 12 years ago by
Replying to jhpalmieri:
Will this interact at all with the class
CombinatorialFreeModule
? I don't know what the long term plans are, or even if there are any, for connecting this withFreeModule
, but the combinatorial version has some nice features.
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 Changed 12 years ago by
To the release manager
Please close #9694 when this ticket is merged.
Changed 12 years ago by
Attachment:  trac_9773abeliangroupsdraft2.patch added 

comment:7 Changed 12 years ago by
Code is stablizing in draft 2 patch, and I'm starting to write the doctests. Still uncertain about __call__
and now its interactions with __contains__
.
There are liberal comments in the code and the units_modn
module has a rather complete demo of functionality.
comment:8 followups: 9 10 Changed 12 years ago by
Question: does this patch solve #10181?
Paul Zimmermann
comment:9 followup: 11 Changed 12 years ago by
comment:10 Changed 12 years ago by
Replying to zimmerma:
Question: does this patch solve #10181?
Short answer: this could speed up subgroups()
by a factor of 8, if my experiments are right. We won't beat Magma, but we won't be embarassed on really small examples. This patch does not have a subgroups()
method yet, but could be easy to add.
Full details at #10181. Thanks for asking.
Rob
comment:11 Changed 12 years ago by
Replying to jhpalmieri:
While we're at it, how about #9940?
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 Changed 12 years ago by
Cc:  Justin Walker added 

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
Changed 11 years ago by
Attachment:  trac_9773abeliangroupsdraft3.patch added 

comment:13 Changed 11 years ago by
Draft 3 patch is actually about a year old at time of posting (for safekeeping). 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 Changed 10 years ago by
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 modulelevel doctests. Little or no errorchecking yet.

_element_constructor()
works fine with module elements, which is to be expected, since it is copied verbatim from there. I cannot seem to make it accept reasonable elements of the parent of the generators for subsequent processing without totally breaking extensive doctests.  The multiplicative version does not pass the
TestSuite
framework. Likely the implementation of multiplicative operators on top of an additive class (FGP modules) is to blame?
I've tried to add copious comments to make it easier to navigate the code. More specific problem areas are flagged with *PROBLEM*
.
Changed 10 years ago by
Attachment:  trac_9773abeliangroupsdraft4.patch added 

comment:15 Changed 10 years ago by
Just replaced the patch. Realized the _user_to_optimized()
method needed to be in the parent class, not the element class. Then had some partial success getting _element_constructor()
to work, but it still fails on subgroups  .smith_form_gens()
for FGP modules is the suspect.
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.
Changed 10 years ago by
Attachment:  trac_9773abeliangroupsdraft5.patch added 

comment:16 Changed 10 years ago by
draft4 failed to include "init.py" in the patch  that has been corrected in draft5.
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 commentedout, but I think they are correctable also.
Changed 10 years ago by
Attachment:  trac_9773abeliangroupsdraft6.patch added 

comment:17 Changed 10 years ago by
draft6 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 FGP_Module
code. Remainder are stray print statements to be cleaned up.
comment:18 followup: 19 Changed 10 years ago by
Cc:  Alex Ghitza added 

Hi Rob,
Just a quick note to say that I've played with draft6 a bit (mainly with the UnitsModmGroup
), and I very much like it. Thanks for all the work you've put into this (and the patience!).
comment:19 Changed 10 years ago by
Replying to AlexGhitza:
Just a quick note to say that I've played with draft6 a bit (mainly with the
UnitsModmGroup
), and I very much like it. Thanks for all the work you've put into this (and the patience!).
Thanks very much, Alex, for the encouragement. Still lots of docstrings to work on, but making (slow) progress, since classes started recently. Soon. ;)
comment:21 Changed 9 years ago by
Milestone:  sage5.11 → sage5.12 

comment:22 Changed 9 years ago by
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:23 Changed 9 years ago by
Milestone:  sage6.1 → sage6.2 

comment:24 Changed 9 years ago by
Milestone:  sage6.2 → sage6.3 

comment:25 Changed 8 years ago by
Milestone:  sage6.3 → sage6.4 

comment:26 followup: 27 Changed 8 years ago by
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 Changed 8 years ago by
Replying to kcrisman:
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.
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.
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, errorchecking, doctests, comparisons, and so on. But the code seems to be working. I'm not 100% confident on the
__call__
method of the main abstract class and I don't know if I need some things to support coercion better. Any advice or comments at this stage would be appreciated before I begin to clean this all up.