ECNF: BSD invariants and display

[JohnCremona]

This is based on #6287 so should not be merged before that [now done].

This addresses the remaining issues from #5409 . Both usual regulator and the Neron-Tate regulator are now displayed. The global period displayed is the stored value times 2**(#complex places) for reasons explained at #5409.

I have also added a BSD Formula section with a display like the one for ECQ. When reviewing that, look at examples for all current ranks (0,1,2,3) and also one where not all the data is available, such as
http://localhost:37777/EllipticCurve/2.0.10691.1/1.0.1/a/1 where the formula section is missing.

There are a lot of details in that formula, so I would welcome comment as I have probably missed something.

[The following remarks remain valid but this issue has been fixed in the latest commit 2ccd9ec.]

Wait: for some of the recently uploaded curves over imaginary quadratic fields, the data was computed and uploaded after I fixed the issue with scaling the complex periods, so the doubling should not be done. And this is made very clear when looking at the new displayed formula (e.g. http://localhost:37777/EllipticCurve/2.0.699.1/93.2/a/1) where the number on the extreme right is double the one on the extreme left, instead of being equal!

It will be possible for me to work out exactly which data this applies to and put in a fix, updating the PR. But everything else is ready for review.

[JohnCremona]

In the latest commit 2ccd9ec I added code to detect whether the global period has been normalised correctly.

• the default, needed because of the values stored up to 2024-07-09 not having the complex periods doubled, is to multiply the global period by 2**#complex places
• this only gives the wrong global period for curves whose data was computed after that date; these are all imaginary quadratics, so the factor is 2 and has already been applied to the stored period
• so I recompute analytic Sha in all cases from the stored data with adjusted period (already needed for the BSD formula display), compare with the stored Sha, and reverse the adjustment when necessary; in all cases this means dividing the global period (which we just multiplied by 2 unnecessarily) by 2.

When this is done I did print a line to the log, which I know is bad practice, but would like to keep in until I have fixed all the data (by renormalising all the stored global period values where necessary).

I apologise for this unhappy (but temporary state of affairs). It is certainly partly my fault, but on the other hand there are many different normalizations in the literature for the various factors appearing in the BSD formula over number fields (I even have a draft paper comparing these to try to make all te differences very explicit), in particular whether you include a separate factor of 2**#complex places, or absorb it into another factor -- as we have done.

On the plus side, please admire the new BSD formula display!

[roed314]

Over $$\mathbb{Q}$$ we use $$=$$ for rank 0 and 1 and $$\overset{?}{=}$$ for rank at least 2. Should we do the same over number fields? I'm a bit uncertain whether BSD is known for curves in the LMFDB over number fields that have rank 0 or 1; they're constructed via modular methods, so do Gross-Zagier and Kolyvagin apply meaning that the full BSD conjecture is known?

[JohnCremona]

Over Q we use = for rank 0 and 1 and = ? for rank at least 2. Should we do the same over number fields? I'm a bit uncertain whether BSD is known for curves in the LMFDB over number fields that have rank 0 or 1; they're constructed via modular methods, so do Gross-Zagier and Kolyvagin apply meaning that the full BSD conjecture is known?

Thanks for catching that, I meant to put the ? in but forgot. Over number fields very much less is known! In general (though our fields are not so general) we don't even know that the curve's L-function has analytic continuation and functional equation. The existence of the formula depends on all those conjectures.

I'll fix it - done: the new commit puts a ? on top of the = in the middle of the formula in all cases.

[roed314]

It looks like there are still issues with dividing by 2: http://localhost:37777/EllipticCurve/2.0.699.1/93.2/a/1

[JohnCremona]

It looks like there are still issues with dividing by 2: http://localhost:37777/EllipticCurve/2.0.699.1/93.2/a/1

Rats, I will look into that. The fields 2.0.D.1 with 600<D<700 are those for which (I thought) the stored Omega was correct with no adjustment, but my fix did not rely on knowing that. In fact, my fix was supposed to not display the formula umless the two sides agreed as a failsafe!

[JohnCremona]

Found the issue -- after the unneeded adjustment it computed Sha=0.5 but that rounded to 1 so the incorrect factor of 2 was not detected. Fix coming up...

[JohnCremona]

The extra fix not only checks that the Sha value computed from the other quantities in the formula agrees with the stored Sha value after rounding (which should detected when the factor of two has been wrongly applied or unapplied) but also checks that the value being rounded is close to the integer it rounds to. This stops the problem where 0.5 rounding to 1 was not being noticed as different from 1.0 rounding to 1.

Please remember that this fix is only temporary, and will be unnecessary when I have recomputed all the global periods for non-totally-real fields to use the new normalization.

[roed314]

It's not an issue to be solved for this PR, but when I look at 2.0.10691.1-1.0.1-a1 the analytic rank is shown as "not available" but the L-function shows the analytic rank as 1.

[roed314]

Looks good!

[JohnCremona]

Thanks a lot for the reviewing, much appreciated.

My script for computing L-functions from elliptic curves calls either Magma (which I used exclusively for most) or Pari (which I started using more recently. This computation is quite independent from the L-function analytic rank (which I think was computed by @edgarcosta ). Recomputing these and the associated real quantities to a higher precision is one of my ongoing projects (for which there is an issue open).

The web page code could ceratinly look to see if there is an L-function with the matching lael and if so, use the analytic rank stored in that table. But for examples such as the one you found this would not add a lot to what we know: we don't have a generator, hence no regulator and no Sha (though we could predict Reg*Sha from the other data).

Something for another issue. It is really quite hard to work out what can be displayed when we do not have complete information.