BSD normalization for some elliptic curve quantities

[JohnCremona]

While computing the factors appearing in the BSD (Birch--Swinnerton-Dyer) conjectural formula for elliptic curves I came across some normalizations which could be made more consistently.

1. If e is a complex (non-real) embedding of a number field K and E is an elliptic curve over K then currently E.period_lattice(e).omega() returns the area/covolume of the period lattice, but in the BSD formula it needs to be doubled. I propose leaving the default as is but adding a parameter which just doubles the returned value. (For real embeddings, omega() already doubles the real period when there are two real components, and there is a case for doubling by default in the complex case but that would be backwards-incompatible.)
2. E.tamagawa_product_bsd() gives the product of E's Tamagawa numbers times a correction factor, needed in BSD, to allow for primes where the current model of E is not minimal. We should also have E.tamagawa_product() for the product without the correction factor; currently this exists only for elliptic curves over Q. The correction factor has nothing to do with Tamagawa numbers anyway.
3. If P is a point on E(K) then P.height() by default normalizes so that it is independent of base-change, and there is an option (normalize=False) not to do that. (Normalization just divides by the degree of K.) But E.regulator_of_points() does not have that option. It should: it is the non-normalized regulatro which appear in the BSD formula.

Component: elliptic curves

Author: John Cremona

Branch/Commit: 540ebb9

Reviewer: David Lowry-Duda

Issue created by migration from https://trac.sagemath.org/ticket/29782

[JohnCremona]

Branch: u/cremona/29782

[JohnCremona]

New commits:

d795058	#29782: bsd normalisation for complex omega
ad17b47	#29782: added tamagawa_product method for elliptic curves over number fields
0aa2359	#29539: added normalised parameter to regulator and height pairing matrix methods

[JohnCremona]

Commit: 0aa2359

[JohnCremona]

comment:2

The three commits address the three points in the ticket description, one each. Doctests have been added. In the last case, the extra parameter was also added to the method height_pairing_matrix() which computes the relevant heights and is called by the regulator method. In all cases where a parameter has been added, it is optional, and the behaviour with the default value is as it used to be.

[JohnCremona]

comment:3

The patchbot "?" was only because of some startup time issue. This ticket has a green light for 9.2.beta7 and can be merged!

[davidlowryduda]

comment:4

I think you should add a description of what normalised means in the documentation for the INPUT block of height_pairing_matrix(). You have already included an example later in the documentation for height_pairing_matrix(), but missed describing it earlier.

The rest looks good to me.

[davidlowryduda]

Reviewer: David Lowry-Duda

[JohnCremona]

comment:6

Will do -- thanks.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

540ebb9

#29782: add missing parameter to docstring

[sagetrac-git]

Changed commit from 0aa2359 to 540ebb9

[JohnCremona]

comment:8

Done. I used the same parameter description as in regulator_of_points.

[davidlowryduda]

comment:9

Good!

[vbraun]

Changed branch from u/cremona/29782 to 540ebb9