Curious case

[jvoight]

Reported by Drew Sutherland:

For the Picard curve

y^3 = 189*x^4+253*x^2+64

if I call HeuristicEndomorphismAlgebraCC using 1000 digits of precision it tells me [RR,RR], which is impossible for a Picard curve. So I have been gradually increasing precision, most recently running at 10,000 digits, and it is still saying [RR,RR].

Now I actually now that this curve has ST group U(1)_3 and a component group of order 24, and in the process of writing this e-mail I actually ran a loop calling HeuristicEndomorphismAlgebraCC with precision increasing from 100 to 1000 just so I could give you something you could reproduce in a reasonable amount of time, and low and behold it actually gives the right answer at 100 digits of precision! And at 200 digits, and at 300 digits, but give it 400 digits or more and it lies.

Here is code to reproduce this behavior (note that I have Christian's oldenberg package installed)

R<x,y>:=PolynomialRing(Rationals(),2); f:=y^3-(189x^4+253x^2+64); for d in [100,200,300,400,500,600,700,800,900,1000] do time print d,HeuristicEndomorphismAlgebraCC(PlaneCurve(ChangeRing(f,RationalsExtra(d))))[3]; end for; 100 [ M_3 (CC) ] Time: 1.720 200 [ M_3 (CC) ] Time: 3.600 300 [ M_3 (CC) ] Time: 6.550 400 [ RR, RR ] Time: 11.360 500 [ RR, RR ] Time: 18.440 600 [ RR, RR ] Time: 27.810 700 [ RR, RR ] Time: 44.320 800 [ RR, RR ] Time: 61.470 900 [ RR, RR ] Time: 83.530 1000 [ RR, RR ] Time: 111.260

[jvoight]

This bug is worrisome, why would it find a matrix (with small integer entries) which preserves the lattice in low precision and then suddenly fail to see that it preserves the lattice in higher precision? Is there a numerical threshold that isn't adapting appropriately? If I were to debug, I'd take the exact matrices giving the "correct answer" in low precision and see why they're failing to be deemed numerical endomorphisms in higher precision.

[edgarcosta]

My bet is that even though the working precision was increased, the accuracy of the period matrix didn't increase accordingly. I will try to look into this tomorrow or over the weekend.

[JRSijsling]

This has to do with precision errors when calculating the period matrix to high precision. The official Magma release of Neurohr's work will likely fix this. To be able to spot trouble like this occurring, use

SetVerbose("EndoFind", 3);

and you can see the LLL steps in the heuristic calculations.

In the meantime, I just pushed a commit that enables faster calculation for the specific case of superelliptic curves, which is based on the work of Molin--Neurohr on computing the period matrices of these curves.

[JRSijsling]

Adding Christian's improved code, the output of Drew's loop is now:

100 [ M_3 (CC) ]
Time: 0.970
200 [ M_3 (CC) ]
Time: 1.170
300 [ M_3 (CC) ]
Time: 1.630
400 [ M_3 (CC) ]
Time: 2.620
500 [ M_3 (CC) ]
Time: 3.570
600 [ M_3 (CC) ]
Time: 5.250
700 [ M_3 (CC) ]
Time: 6.810
800 [ M_3 (CC) ]
Time: 9.500
900 [ M_3 (CC) ]
Time: 12.550
1000 [ M_3 (CC) ]
Time: 16.130

This solves the issue