Trac #29511: Broken coercion between cyclotomic fields

Skip to first unread message

Kiran Kedlaya

Apr 18, 2020, 6:30:44 PM4/18/20
to sage-nt
I've already created ticket #29511 for this, but to advertise this more broadly: there seems to be an issue with the canonical embedding of one cyclotomic field into another, where elements that come from the subfield cannot always be coerced back.
sage: K.<z> = CyclotomicField(12)
sage: K1.<z1> = CyclotomicField(3)
sage: K(z1) in K1
sage: K1(K(z1))
sage: K(2) in K1 ## This is the source of the trouble
sage: K1(K(2)) ## Error!

I am up for trying to fix this myself, but I probably need some help from someone who understands coercion in Sage better than I do.


John Cremona

Apr 20, 2020, 3:45:56 AM4/20/20
to sage-nt

Did this ever work?

When I have needed to work in several nested cyclotomic fields I have
done this using the Lord of the Rings strategy "One ring to contain
them all": define the largest one first and then define the subfields
with explicit embeddings. Taken from code at I have The following lines which first
define Q(zeta_1092) and then various subfields. All that worked.
However I tried changing your second line to
K1.<z1> = CyclotomicField(3, embedding=z^4)
and it did not help.


Q1092.<zeta1092> = CyclotomicField(1092)
conj1092 = Q1092.hom([zeta1092^(-1)]) # complex conjugation on Q1092
Q13.<zeta13> = CyclotomicField(13, embedding=zeta1092^84)
eQ13Q1092 = Q13.hom([Q1092(zeta13)]) # embedding Q13 into Q1092
Q13sigma = Q13.hom([zeta13^4]) # auto of order 3 of Q13
Q13aut = Q13.hom([zeta13^2]) # auto of order 6 of Q13
Q91.<zeta91> = CyclotomicField(91,embedding=zeta1092^12)
eQ91Q1092 = Q91.hom([zeta1092^12]) # embedding Q91 into Q1092
eQ13Q91 = Q13.hom([zeta91^7]) # embedding Q13 into Q91
Q91aut = Q91.hom([zeta91^53]) # auto of order 3 of Q91 fixing Q13
Q84.<zeta84> = CyclotomicField(84, embedding=zeta1092^13)
conj84 = Q84.hom([zeta84^(-1)]) # complex conjugation on Q84
Q12.<zeta12> = CyclotomicField(12, embedding=zeta84^7)
Q7.<zeta7> = CyclotomicField(7, embedding=zeta84^12)
Q1092._latex_ = lambda: "\mathbb{Q}(\zeta_{1092})"
Q13._latex_ = lambda: "\mathbb{Q}(\zeta_{13})"
Q91._latex_ = lambda: "\mathbb{Q}(\zeta_{91})"
Q84._latex_ = lambda: "\mathbb{Q}(\zeta_{84})"
Q12._latex_ = lambda: "\mathbb{Q}(\zeta_{12})"
Q7._latex_ = lambda: "\mathbb{Q}(\zeta_{7})"
Q7p.<zeta7p>=NumberField(zeta7p.minpoly(), embedding=zeta7+1/zeta7)
zeta13pp = zeta13+zeta13^5+zeta13^8+zeta13^12 # generates cubic subfield
Q13pp.<zeta13pp> = NumberField(zeta13pp.minpoly(), embedding=zeta13pp)
eQ13ppQ13 = Q13pp.hom([Q13(zeta13pp)])
zeta13c = zeta13+zeta13^3+zeta13^9 # generates quartic subfield
Q13c.<zeta13c> = NumberField(zeta13c.minpoly(), embedding=zeta13c)
eQ13cQ13 = Q13c.hom([Q13(zeta13c)])
Q7p._latex_ = lambda: "\mathbb{Q}(\zeta_{7}^{+})"
Q13pp._latex_ = lambda: "\mathbb{Q}(\zeta_{13}^{++})"
Q13c._latex_ = lambda: "\mathbb{Q}(\zeta_{13}^{c})"
> --
> You received this message because you are subscribed to the Google Groups "sage-nt" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> To view this discussion on the web visit

Vincent Delecroix

Apr 20, 2020, 4:23:22 AM4/20/20

I don't think it ever worked. However it is a desirable feature
to have. As I mentioned on the ticket, there is already code for
this (which works for general number fields)

sage: K12.<z12> = CyclotomicField(12)
sage: K3.<z3> = CyclotomicField(3)
sage: f = K3.hom([z12^2 - 1])
sage: f.preimage(-3*z12^2 + 3)

This is basically what the code for K3(-3*z12^2 + 3) should be


Kiran Kedlaya

Apr 20, 2020, 12:41:03 PM4/20/20
to sage-nt
Indeed, this appears to have never worked, but the issue is not to do with choices of embeddings. In fact cyclotomic fields are implemented with a preferred choice of embeddings: the map from CyclotomicField(m) to CyclotomicField(m*n) always takes zeta_m to zeta_n^m.

There is some interesting archaeology to be done in, where this problem seems to originate; the function _coerce_from_other_cyclotomic_field is the offender. There is some commented-out code that tried to fix this; the author indicates that the fix failed because it broke doctests for Eisenstein submodules. I didn't try to figure out who wrote this comment, or how long ago, but it appears to be not recent.

Anyway, since there is a working method as Vincent points out, it should be a relatively easy fix to patch this in.

>> To unsubscribe from this group and stop receiving emails from it, send an email to
Reply all
Reply to author
0 new messages