OK. In that case I'll upload a fix for #5250 without addressing this issue, and just fudge the multiplicative_subgroups method so it returns the same wrong output it did before, so the doctest in congroup_gamma0 passes. Once we have a new abelian groups framework based on #5882, someone can then go away and write a "subgroups" method for arbitrary abelian groups which gives correct output, and we can fix multiplicative_subgroups using that.
David On May 6, 8:46 pm, William Stein <wst...@gmail.com> wrote: > 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/5882lately. > > > 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 -~----------~----~----~----~------~----~------~--~---