Sage interface

[edgarcosta]

Just posting some ideas regarding a possible Sage interface for LMFDB.
Feel free to comment, I just wanted to make this discussion public.

The pylmfdb ( https://github.com/csbrady-warwick/pylmfdb ) is a proof of concept for a sage interface using the existing API, wrote by Chris Brady.

Quoting Chris:

It does more or less
show how I'm planning to implement the Sage/Python end of the API2 (for
want of a better name) system though, so I'd suggest maybe using it as a
base (if you don't think it's too incomplete to be useful) might make it
easier to combine with the newer design later.

The goal would be converting a JSON into a Sage object, where a lot of functionality would be inherited from standard class in Sage, but default option would be to use the database data instead of recomputing it.

Regarding specific tasks for the next steps, to extend pylmfdb and help Chris would be:

the main thing that would be helpful to us is a
description of the Sage objects (either already existing or not) a
mathematician would want to work with that use data from LMFDB, and what
data they use from LMFDB. What searches people would likely want to make
on the data and also, is there anywhere where data is needed that is not
in the LMFDB database and must be computed? The API2 system itself will
just be a fairly thin (but more complete than the current API and not
tied to the specific database structure) layer that provides data from
LMFDB, but we do need to know what we're targetting for the end user. I
know that that isn't a short document and it might be hard to write
without everyone who wrote all the parts involved, but I think that it'd
be useful for everyone to know as much as possible about what the end
use case is.

[davidlowryduda]

At Sage Days 87, Simon Brandhorst and I prototyped another interface. This builds on Chris Brady's pylmfdb, but gives a more complete sage object at the end of the day. The code is available on my github: https://github.com/davidlowryduda/sage2lmfdb

But a better demonstration is available here, as a jupyter notebook. [I should note that I did a time test somewhere in there, and I later fixed it to be much much faster. So ignore that cell].

Here are the relevant thoughts. From the frontend: for objects of interest, we write subclasses of the corresponding sage class. In this case, we wrote an lmfdb_elliptic_curve class that subclasses an elliptic_curve class from sage. We override the relevant methods one would use from sage (for instance, to compute generators) to give data from the lmfdb when available. There are some implementation choices there that aren't particularly important now. From the backend: calls are made to the web API. These are based off of Chris's api module. Of course, there are some changes that need to be made to the API.

I gave this demo at Sage Days, and there were a few questions that were asked afterwards. A couple people asked me whether or not it is possible to just compose pymongo queries and send these to the LMFDB. This is not currently possible, and this is a different thought process than the one provided in this demo. But one might hope that there could be a persistent read only copy of the database that could be queried against a bit more casually, especially if we limit or kill any query that takes more than x seconds. If we were to take such an approach, this could influence what an interface between sage and the LMFDB could look like.

The other comment that I received the most from Sage Days is that it's very important to be able to query in ranges, such as finding curves with conductor between x and y. This is not currently exposed through the http API.