Trac #29511: Broken coercion between cyclotomic fields

[Kiran Kedlaya]

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
True
sage: K1(K(z1))
z1

sage: K(2) in K1 ## This is the source of the trouble

False

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.

Kiran

[John Cremona]

Kiran,

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
https://arxiv.org/abs/1306.6818 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.

John

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})"
zeta7p=zeta7+1/zeta7
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 sage-nt+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-nt/d4708760-19b2-4a5c-a0b4-756eb592b08c%40googlegroups.com.

[Vincent Delecroix]

John,

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)
-3*z3

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

Best
Vincent

[Kiran Kedlaya]

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 number_field.py, 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.

Kiran

>> To unsubscribe from this group and stop receiving emails from it, send an email to sag...@googlegroups.com.