Conductor_Genus2 gives incorrect output on some curves

[AndrewVSutherland]

I have heuristically computed the conductor 834 of y^2 = 16*x^5 + 88*x^4 + 65*x^3 - 170*x^2 + x using the algorithm described in https://arxiv.org/abs/1602.03715. While this computation is heuristic, it proves that the the functional equation cannot be satisfied (for any choice of Euler factor at 2) if the conductor is 417, which is the value returned by Conductor_Genus2. Moreover, assuming modularity, there are no abelian surfaces with conductor 417 (see Corollary 2.4 of https://arxiv.org/abs/1502.00850), so I believe there must be a bug in Conductor_Genus2.

This curve is one of many that we will be adding to the LMFDB that have small conductors but may have discriminants that are much larger than the bound 10^6 on the current data set. Conductor_Genus2 gives output that I believe is incorrect for many of these curves (about 2 percent of the cases I have tested so far), possibly due to the same bug that is occurring here (I'm happy to provide more examples if that would be helpful for debugging/testing).

Code to reproduce the problem appears below:

> AttachSpec("ExactpAdics2/spec");   
> AttachSpec("Genus2Conductor/spec_ExactpAdics");
> R<x> := PolynomialRing(Rationals()); C := HyperellipticCurve(R![0, 1, -170, 65, 88, 16], R![]);    
> Conductor_Genus2(C);
Warning (get_approx): need to increase precision of defining polynomial (32 -> 
1375) for unknown reasons
Note: you can suppress future warnings with 
ExactpAdics_SetWarningAction("get_approx", "Ignore")
Warning (get_approx): need to increase precision of defining polynomial (2048 ->
2060) for unknown reasons
Note: you can suppress future warnings with 
ExactpAdics_SetWarningAction("get_approx", "Ignore")
417

[cjdoris]

Very curious! Thanks for the bug report, I agree there must be an error. Most likely it's a factorisation error.

Unfortunately I'm not in maths research any more, though I might still have a Magma license somewhere and could take a look in some spare time.

You could try changing to the global proof method (argument Proof := "Global") which might have some effect, though it shouldn't.

If you're able, could you verify the conductors already in the LMFDB? When the paper was written, my code agreed with the database, so if they disagree now then something must have changed in Magma to mess up the p-adics. Or alternatively try an older version of Magma (circa 2017) on your curves.

[AndrewVSutherland]

@cjdoris Setting Proof := "Global"' has no effect (as expected). Last night I ran Conductor_Genus2 on the 66158 curves in the LMFDB and it correctly computed the conductor for all but two of them. It seems to be stuck on the two remaining curves (it has been running for 10 hours on each of them now, whereas it took 4 minutes or less for all the others, just 2 seconds per curve on average). But it never returns the wrong answer (which is good! I'd much rather have it get stuck than give the wrong answer), so I think the problem I am reporting here is likely caused by it hitting a code path inside Conductor_Genus2 that hasn't been exercised before, rather than a Magma change. This would not be surprising, as the discriminant bound on the curves in the LMFDB is a strong restriction that makes certain edge cases impossible.

The two LMFDB curves that Conductor_Genus2 seems to be stuck on are 3616.b.462848.1 and 18816.d.602112.1.

If it help you to debug this, I would be happy to setup an account for you on one of our development machines that has the current version of Magma (2.26-10) installed -- just email me your public ssh key. Any time you are willing to spend on this would be greatly appreciated! (but I of course understand if you do not have time).

[cjdoris]

You can cancel those two curves it's hanging on - we had the same issue, it's Magma struggling to compute a regular model. For these two cases we could get a regular model by hand. Still, knowing you're getting the same results narrows things down.

My money is on numerical error. The exact p-adics machinery wraps Magma's finite precision p-adics, which have always been a bit buggy. The exact p-adics has some heuristics to perform computations at higher precision than necessary to work around this. Maybe those heuristics are wrong in this case, particularly if your curves have high discriminant.

Can your method say whether the conductor exponent at 2 is tame or wild? That would narrow it down.

I'll send you my SSH key next time I'm at my computer.

[AndrewVSutherland]

Thanks! I believe the conductor exponent at 2 is 1 and the Euler factor is 1+T^2-2*T^3 (the functional equation is satisfied to high precision with these choices).

[AndrewVSutherland]

I don't know if this is relevant, but Magma is also badly confused by this curve: if you ask for the Euler factor at 2 you get 15*T^4 + 11*T^3 + 7*T^2 + 3*T + 1, which is of course nonsense.

[cjdoris]

I have emailed you my public SSH key. Its SHA256 checksum is acb93c8d805b436b207a067d65aeac46370cbdc233062f958757a4f92b214ac3. My surname has changed - it is me!