Opened 11 years ago
Last modified 3 years ago
#7234 needs_work enhancement
Unit groups for finite fields (and more generally)
Reported by:  fwclarke  Owned by:  tbd 

Priority:  major  Milestone:  sagewishlist 
Component:  algebra  Keywords:  unit group, finite field, ring 
Cc:  rbeezer, cremona, kcrisman, slelievre  Merged in:  
Authors:  Francis Clarke  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/7234 (Commits, GitHub, GitLab)  Commit:  34e980d10668c9f3db1b040e6ddfcb798c528d51 
Dependencies:  Stopgaps: 
Description
The attached patch implements unit groups for finite fields. It is modelled on John Cremona's code for the unit groups of number fields. One difference is that if F is a finite field, while F.unit_group() yields the group of units (just as for a number field), F.unit_group(n) gives the group of nth roots of unity.
I have designated it as "needs work" for two reasons:
 Both pieces of code deserve generalising to more general rings. In
particular, Rob Beezer has expressed a need to have the group of units of the integers modulo n.
 There are certain aspects of the notation/terminology/implementation
that I am not totally happy with. Maybe F.unit_group(n)
is not such a
good idea. Also it seems
odd that one has
sage: F.<g> = FiniteField(16) sage: UF = F.unit_group() sage: UF.gen() g sage: g in UF True
but
sage: UF(g) u sage: UF(1 + g + g^3) u^7
It's similar for number fields:
sage: K.<a> = NumberField(x^3  39*x  91) sage: UK = K.unit_group() sage: UK.gens() [1, a^2  4*a  22, a + 3] sage: UK(a + 3) u2
Note also that UF(UF(g))
and UK(UK(a + 3))
both lead to errors.
Deciding how to be more consistent probably needs to be done at a more
general level and will most likely best be done by introducing a class
UnitGroupElement
based (for commutative rings anyway) on
AbelianGroupElement
, something that has been avoided in the finite field
and number field cases.
Attachments (1)
Change History (8)
Changed 11 years ago by
comment:1 Changed 11 years ago by
 Status changed from new to needs_work
 Summary changed from [with patch, needs work] Unit groups for finite fields (and more generally) to Unit groups for finite fields (and more generally)
comment:2 Changed 11 years ago by
comment:3 Changed 3 years ago by
 Cc slelievre added
 Keywords changed from unit group finite field ring to unit group, finite field, ring
 Report Upstream set to N/A
This feature is requested in
Francis or John, would you turn the patch into a branch?
The group of roots of unity could be for another ticket if that is the blocking point.
comment:4 Changed 3 years ago by
 Branch set to public/7234
 Commit set to 2002e79f09df02df31968cde474b04b10a5ebf43
here is a branch, refreshed, but not working
New commits:
2002e79  creating the git branch outside of patch, refreshed

comment:5 Changed 3 years ago by
 Commit changed from 2002e79f09df02df31968cde474b04b10a5ebf43 to 34e980d10668c9f3db1b040e6ddfcb798c528d51
Branch pushed to git repo; I updated commit sha1. New commits:
34e980d  fixing doctests

comment:6 Changed 3 years ago by
now working again
When I implemented that for number fields I ran into these issues. Initially I tried to construct a UnitGroupElement? but gave up  the problem I faced was the underlying AbelianGroup? class, and that has not (yet) improved.
Concerning
(Z/nZ)^*
, note that this is implemented over number fields (by me and Maite) using pari functions for that, including generalised discrete logs. Sage already has Integers(n).unit_group_gens() using some native code; it could also use pari.