Isogenies over number fields

[Chris Wuthrich]

Hi

I haven't played with isogenies for a while but did so a lot recently. As I am no longer really familiar with the new structure in sage, I sent this message to this group in the hope that someone involved in isogenies in sage picks it up. I list a few separate issues and questions in one email. Sorry for its length.

I am happy to help (modulo time constraints) and feel free to contact me directly outside this forum.

---

a) Here is a first error, which I assume is a bug

F.<s> = QuadraticField(-3)
E = EllipticCurve(F,[0,0,1,0,0])  # has cm by O_F
R.<x> = F[]
phi = E.isogeny(x,codomain=E,degree=3)  # is an associate to sqrt(-3)
psi = 1 + phi
psi.rational_maps()

it causes boom with "TypeError: polynomial (=2) must be a polynomial"

Related to this, one of the statements

sage: (phi+1).degree(), (phi-1).degree()

7,7

is wrong as the only possible answers for associates of sqrt(-3) in F are

7,1 or 1,7 or 4,4.

---

b) Here is my next problem, continuing from the above

phi7 = E.isogeny(x^3 + 3/14*s - 1/14, codomain=E, degree=7)
xi = -2 + phi7   # should be the automorphism of order 3
xi.degree()

goes boom with "ValueError: the two curves are not linked by a cyclic normalized isogeny of degree 7" at the last line not before. I know now that I should use .automorphism instead.

---

c) This is again a bug which results in an incorrect answer rather than an unexpected error.

k.<z> = GF(25,"z")

R.<x> = k[]

A = EllipticCurve(k, [0,4,0,2,4])
f = x^3 + (3*z + 2)*x^2 + (z + 4)*x + z + 2
phi = A.isogeny(f)
alpha = next(a for a in A.automorphisms() if a.order()==3)

phi.kernel_polynomial(), (phi*alpha).kernel_polynomial(), (phi*alpha*alpha).kernel_polynomial()

returns

(x^3 + (3*z + 2)*x^2 + (z + 4)*x + z + 2, x^3 + 2*z*x^2 + 4*z*x + 4*z + 3, x^3 + (3*z + 2)*x^2 + (z + 4)*x + z + 2)

while the first two are correct, the last is incorrect as it can definitely not be the same as the first. It should be 

f.subs(alpha.u^2*x+alpha.r)

x^3 + 2*x + 4

d) Here is an unexpected behaviour. An isogeny cannot be __call__ed on a point over a larger field, but it can be _eval-ed:

This works fine:

E = EllipticCurve(GF(7),[1,3])  # rather randomly chosen
phi = E.isogenies_prime_degree(3)[0] # unique
L.<z> = GF(7^2)
EL = E.base_extend(L)
P = EL([1,2+3*z]) # random
phi._eval(P)

but

phi(P)

throws 

"ValueError: 3*z + 2 is not in the image of (map internal to coercion system -- copy before use)

Ring morphism:
  From: Finite Field of size 7
  To:   Finite Field in z of size 7^2"

---

e) Is there a way to base_extend phi to L? That shouldn't be hard to implement. My hand-on implementation of this is not really good, but it worked.

Similarly, I wrote a "reduction" for an isogeny over a number field at a prime ideal where the model has good reduction. In both cases I extended/reduced the kernel polynomial and created a new isogeny on the extended/reduced curves and then adjusted it with an automorphism if the .scaling_factor did not extend/reduce to the new scaling_factor. Of course, for composite and sum morphisms I did it on the components. But it feels like one should be able to do this directly.

Again, apologies for the length of this post.

Chris

[John Cremona]

Hi Chris,

I wrote some of this stuff and will look into it, but there has been a lot of newer work by others, people interested only in finite base fields, and that might be relevant.  But I'm away at the moment so I cannot do anything for a few days.

John

--
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/CABMU80cWGcb0Vm41Tumjjc5Aoh9mAZkwc_gBv52a9rSYNwT0Vg%40mail.gmail.com.

[John Cremona]

On Thu, 8 Aug 2024, 18:10 John Cremona, <john.c...@gmail.com> wrote:

Hi Chris,

I wrote some of this stuff and will look into it, but there has been a lot of newer work by others, people interested only in finite base fields, and that might be relevant.  But I'm away at the moment so I cannot do anything for a few days.

Meanwhile it wouldn't hurt to make a GitHub issue (or several) with your bugs.  They might be very easy to fix.