Elliptic curves over Q should be included in ECNF search results

[AndrewVSutherland]

While there are good reasons to retain the current separation between the EC/Q and EC/K browse pages, from a mathematical perspective searches for elliptic curves over number fields should include elliptic curves over Q in the search results when they match the specified criteria. The links for elliptic curves over Q in the search results should take you the existing home page for the elliptic curve, the only change being proposed here is the inclusion of elliptic curves over Q in EC/K searches.

One point worth noting: an elliptic curve over Q can of course be base-changed to any number field, and many of these base changes are already included in the ec_nfcurves database. These can be excluded from the search by choosing to exclude base changes in the search. When base changes are not excluded, the search results may include an elliptic curve over Q along with many of its base changes. This is fine and is already the case, see

https://www.lmfdb.org/EllipticCurve/?hst=List&conductor_norm=729&include_base_change=only&jinv=0&search_type=List

for example. But we should not add base changes that are not already present in the ec_nfcurves database; so in particular, if an elliptic curve over Q matches your search, you will only see the base changes whose conductors lie within the conductor bounds for the field of the base change. This means you will not see base changes to every field, only a fairly small subset of them.

[AndrewVSutherland]

@JohnCremona @roed314 What is the sort order for ecnf? (this should be easy to figure out from the code and/or db_backend, but I cannot find it). I don't understand why the curves over Q(sqrt(-11)) come before curves over Q(sqrt(-3)) (I suspect it may be doing an alpha sort on the label, which is definitely not what we want).

In any case, I think the sort should be by analytic conductor (which in this case means just the conductor) as it is in CMS (and in EC/Q and in genus 2 curves), followed by something else we should agree on.

This is relevant to what you will see see once we include elliptic curves over Q in the search results.

[edgarcosta]

{'conductor_label', 'conductor_norm', 'field_label', 'iso_nlabel', 'number'}

On Fri, Sep 11, 2020 at 12:16 PM Andrew Sutherland notifications@github.com wrote:

@JohnCremona https://github.com/JohnCremona @roed314 https://github.com/roed314 What is the sort order for ecnf? (this should be easy to figure out from the code and/or db_backend, but I cannot find it). I don't understand why the curves over Q(sqrt(-11)) come before curves over Q(sqrt(-3)) (I suspect it may be doing an alpha sort on the label, which is definitely not what we want).

In any case, I think the sort should be by analytic conductor (which in this case means just the conductor) as it is in CMS (and in EC/Q and in genus 2 curves), followed by something else we should agree on.

This is relevant to what you will see see once we include elliptic curves over Q in the search results.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMFDB/lmfdb/issues/3837#issuecomment-691187469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACO2BXI2TI4YLZLKVYSPDLSFJENDANCNFSM4NA4GQEQ .

[JohnCremona]

I had some thoughts about this issue but have not had time to write them down before.

It would be quite easy to write a script which goes through all the EC/Q and creates from each a row in the ECNF table, since we have at least as much (in fact more) data for each EC/Q. If we did just that it would not be very good since EC/Q would have two different web pages, but bear with me. Secondly, we could create a new table for EC/Q only holding the columns with no ECNF analogue. Thirdly, when displaying a curve's home page we could use the existing EC/Q template if the base field is Q and the existing ECNF template otherwise. That would deal with most parts of this issue -- but there would still be a question about whether we would want to keep a separate search page for EC/Q (surely yes).

There may be good reasons why this is a bad way of doing it, but still I thought it worth putting this out there for consideration.

[AndrewVSutherland]

@edgarcosta I beg to differ, see https://www.lmfdb.org/EllipticCurve/?hst=List&include_base_change=only&torsion_structure=%5B9%5D&search_type=List

for example.

[AndrewVSutherland]

@JohnCremona This is an interesting idea. It would avoid the slightly annoying need to interleave search results as I was planning to do -- I'm realizing this is more of a pain now that we are using the standardized search parser to generate the results table, which wasn't designed with this situation in mind.

[edgarcosta]

I was wrong, as I had looked into db.ec_nfcurves._sort_keys before, which gives you an unsorted version of the sort.

sage: db.ec_nfcurves._sort
Composed([Identifier('field_label'), SQL(', '), Identifier('conductor_norm'), SQL(', '), Identifier('conductor_label'), SQL(', '), Identifier('iso_nlabel'), SQL(', '), Identifier('number')])

[AndrewVSutherland]

We should wait to to this until #3900 is addressed, since this will likely add more columns to ec_nfcurves.