Lfunctions database format, string -> list of strings

[edgarcosta]

EDIT: The initial idea of this issue, converting strings to list of strings didn't make much sense, but the generated discussion might be relevant.

Hello,

In Warwick, we seemed to agree that L-functions should be an object by themselves, and we should track their origin.
To be able to track multiple origins and types, I believe that we should switch from
origin, url and type from a single string to a list of strings.
This, should not break the website.
as

db.collection.find( { <field> : <value> } )

returns the objects that contains at least one element with the specified value or are the value itself.
see: https://docs.mongodb.com/manual/tutorial/query-arrays/

On the same note, we also seemed to agree that the Lhash of a primitive L-function should be based on its first zero, precisely

str((<first zero> * 2^100).round())

and if we did not compute the first zero with enough precision we should append an underscore to it.
At the moment, the Lhash is set as a string, I propose we also switch it to a list of strings.
Here I also don't expect that we need to switch any code.
Further, the current values of LHash
are either of the form
/ModularForm/GL3/Q/Maass/1/1/-13.5965_-4.76468/1.04846245/ or 1428752966040989219 (a 61 bit integer in string format).
Thus by adding data to the database with the new proposed format will not create any hash collision.
However, in the future doing

db.Lfunctions.instances.find( { "Lhash" : '24287529660409892113319342424234' } )

will return all the Lfunctions that have as a primitive favor an L-function with its first zero around ~19.1594.
If we only want to grab the the primitive L-function, we would need to do

db.Lfunctions.instances.find( { "Lhash" : ['24287529660409892113319342424234'] } )

A couple of questions:

• Does this make sense to you?
• Can I add data to the DB in the new format? (it would be mostly elliptic curves over real quadratic fields)
• How do you want to handle the case that we know that an origin exists, but we don't have it in the database? Should we still add the theoretical url, origin and type to the Lfunction object? Or should we let the website handle it case by case? (that is the current status, see: http://beta.lmfdb.org/L/EllipticCurve/Q/127781/a/) ?

Cheers,
Edgar

ps: I also find weird the choice of having a "/" in the beginning of the Lhash in the example above.

[AndrewVSutherland]

Several quick comments (which should be read with the understanding that I was not present for the discussions on this topic at the recent workshop, people should feel free to chime in with corrections/clarifications to reflect anything I have missed or misunderstood):

• I agree that the hash should not depend on the origin or any instance specific information.
• As I understand it, the "origin" of an L-function is merely a historical record of where we happened to first encounter the L-function, it is not a mathematically defined property. The connection between an L-function and objects in the LMFDB that have that L-function should be via the instances collection.
• As discussed in Hash GL_2 modular forms #2123, I think it makes sense to have (at least) two distinct hashes (stored in different fields, not in a list!), one based on the first zero and another based on ap values (the later would apply only to arithmetic L-functions).
• No matter what we do, we should not store hashes in a list, both for performance reasons (lookups on lists are much more expensive then exact matches), and structural reasons (the hashes your propose to put in a list are semantically different things, not multiple instances of the same thing).
• Please don't insert data into the Lfunctions collections that does not conform to the current schema until a new schema has been agreed. If you want to experiment, you can create copies and/or new collections in the test db which exists for this purpose.

[edgarcosta]

Thanks for your comments.

• I'm happy with that definition of origin, but if that is the case, it should be documented. Who can confirm that so we can add it to https://github.com/LMFDB/lmfdb-inventory/blob/master/db-Lfunctions.md ?

• I should have known that lists are bad. For the analytic hash, we can easily deal with it by concatenating everything into a string (with no spaces), e.g.:
  "19075381188746980701099336293276,24287529660409892113319342424234"
  The arithmetic should not have these issues if we follow what is being suggested in Hash GL_2 modular forms #2123.

• How should one deal with an L-function with two or more instances?
  Add multiple entries to lfunctions.instances with the same Lhash, but different url?
  So far, we are doing everything case by case on the website, e.g.:
  http://beta.lmfdb.org/L/EllipticCurve/Q/20/a/ is loaded from the database, however,
  http://beta.lmfdb.org/L/ModularForm/GL2/Q/holomorphic/20/2/1/a/0/ is computed on the fly.

• I won't upload anything until we have agreed on everything.

[davidfarmer]

How should one deal with an L-function with two or more instances?

Answer: There should be several entries in lfunctions.instances, all of which point (via the hash)
to the same L-function. Whenever a "new" primitive L-function is uploaded, it is the responsibility
of the uploader to check if it already exists. If it does, then only an instances entry is created.

[davidfarmer]

"the hash should not depend on the origin or any instance specific information"

That would be nice, but it may not be possible in all cases, because we cannot generate
complete information about the L-function in all cases. Examples are:

a) The degree 4 L-function of conductor 550. We know it comes from a Siegel modular
form, but we do not know the associated abelian surface and so cannot compute many coefficients.

b) Almost all the L-functions associated to Maass forms (on GL(2), GL(3), GL(4), and SL(4))

I suggest that the hash used initially be considered provisional, and it can be change
if/when more is known about the L-function.

Or maybe it is possible, if we use a name/hash which just encodes what we know -- which
in all the cases listed above is (conjecturally) enough to uniquely specify the L-function.
And (as Drew wanted) does not involve the origin.

[AndrewVSutherland]

@davidfarmer I like the idea of having an L-function identifier that is intrinsic to the L-function and encodes enough information to (conjecturally) uniquely determine it; from my perspective the various hashes we are considering are convenient ways to search for L-functions (especially when one doesn't necessarily know things like the conductor that might appear in its identifier), but not necessarily the right way to identify/label them.

[edgarcosta]

@davidfarmer Thanks for the clarification regarding multiple instances!

Regarding the hashes, from the analytic side, if there is not enough information to compute the first zero to the desired precision, @arbooker set it to 100 bits, we should just do our best to compute the first zero and append an underscore to denote that not all digits are correct.
In terms of hashing, this underscore doesn't make any difference and it is just an indication that the hash might change in the future.

What do you think about this?

[edgarcosta]

We are pursuing some of these discussions by email.
I will edit
https://github.com/LMFDB/lmfdb-inventory/blob/master/db-Lfunctions.md
later on.