On Wed, May 6, 2009 at 12:13 PM, John Cremona <john.crem...@gmail.com> wrote: > > 2009/5/6 William Stein <wst...@gmail.com>: >> >> On Wed, May 6, 2009 at 11:33 AM, davidloeffler <dave.loeff...@gmail.com> >> wrote: >>> >>> On May 6, 7.10pm, William Stein wrote: >>>>Crap. Thanks for spotting this. Fortunately this is used in only >>>> one place in Sage; this one line in congroup_gamma0.py: >>>> >>>> return [GammaH(N, H) for H in R.multiplicative_subgroups()] >>> >>> Yes, that was how I noticed this -- my fix for 5250 caused >>> multiplicative_subgroups to give a different answer when n = 2, which >>> broke the doctest for that function in congroup_gamma0. >>> >>> On May 6, 7:13 pm, John Cremona <john.crem...@gmail.com> wrote: >>>> Do we have a function which returns (Z/NZ)* as an abelian group? >>> >>> Somehow secretly we do, because it's embedded in the DirichletGroup >>> machinery; but nothing that explicitly creates an AbelianGroup object. >>> >> >> Just some clarification. The functionality to do that is not embedded >> in the DirichletGroup machinery -- what's embedded is that the >> functionality is *used* there, so David knows it must be in Sage >> somewhere :-). >> >> Here's an example of how to get an explicit description of (Z/NZ)^* as >> a product of cyclic abelian groups: >> >> sage: R = Zmod(341) >> sage: R.unit_gens() >> [156, 34] >> sage: [a.multiplicative_order() for a in R.unit_gens()] >> [10, 30] >> sage: euler_phi(341) >> 300 >> >> Thus (Z/341Z)* = Z/10Z + Z/30Z with the map sending (1,0) to 156 and >> (0,1) to 34. > > OK, so if anyone did want to implement a class for > multiplicative-group-mod-N then all the needed machinery is already > there. I had tried r.<tab> ut had not see the unit_gens() function. > >> >> Being able to work with abelian groups in all kinds of different >> "arrangements" and with subtle relations between them is one of the >> most critical and central tools needed in implementing computational >> number theory algorithms. That's why I've put a lot of work into >> http://trac.sagemath.org/sage_trac/ticket/5882 lately. > > I did not know of that work, which looks very interesting (and will > perhaps make AbelianGroup, as currently implemented, redundant?)
Yes. The plan is that once 5882 is done (and optimized), then we'll implement abelian groups very easily as a light wrapper around the code at 5882. And finally, after long last, somebody will successfully (re)write abelian groups in Sage! -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---