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
-~----------~----~----~----~------~----~------~--~---

Reply via email to