LMFDB / lmfdb

L-Functions and Modular Forms Database
Other
246 stars 198 forks source link

Wishlist: search option "disjoint from" a set of primes for bad primes #3771

Open AurelPage opened 4 years ago

AurelPage commented 4 years ago

It would often be useful to be able to specify a list of primes that you don't want to be bad. This probably applies to many objects, but I am mainly thinking about classical modular forms ("Bad p" field); note that it could also be a separate search field like for global number fields ("Unramified primes" field).

The automatic "similar issues" feature of github suggests #3160, which makes me realise that specifying the number of bad primes also makes sense and could also be useful for modular forms.

edgarcosta commented 4 years ago

Would be enough to have an option of "exclude" as in https://www.lmfdb.org/EllipticCurve/Q/ ?

On Wed, 25 Mar 2020 at 09:49, AurelPage notifications@github.com wrote:

It would often be useful to be able to specify a list of primes that you don't want to be bad. This probably applies to many objects, but I am mainly thinking about classical modular forms ("Bad p" field); note that it could also be a separate search field like for global number fields ("Unramified primes" field).

The automatic "similar issues" feature of github suggests #3160 https://github.com/LMFDB/lmfdb/issues/3160, which makes me realise that specifying the number of bad primes also makes sense and could also be useful for modular forms.

— 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/3771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACO2BRB3HLZSHFOI6YYEO3RJIDVDANCNFSM4LTOZPQA .

AurelPage commented 4 years ago

Yes, "exclude" is the same as "disjoint from".

edgarcosta commented 4 years ago

I'm aware that "exclude" = "disjoint from", but the question would it be enough to have a single box, or are you asking for two boxes, as in number fields https://www.lmfdb.org/NumberField/?

AurelPage commented 4 years ago

Either would be fine, but of course two boxes allow for finer searches. This could also be an opportunity to uniformise the way it is done in various objects: several search fields vs only one, formulation ("include" vs "superset") etc.

edgarcosta commented 4 years ago

We have been trying to uniformize the search. Take a look at: https://olive.lmfdb.xyz/NumberField/ At the moment, seems that only place we are missing the exclude option is classical modular forms.

AurelPage commented 4 years ago

I see, thanks! It seems that only number fields has a separate search box, so maybe simply adding an "exclude" option to the "Bad p" box of modular forms is reasonable.

JohnCremona commented 4 years ago

I think we should be consistent across all objects we have which have a notion of bad or ramified primes, which is a lot of them. We should have the same search options for all these using as similar wording as possible

rbommel commented 4 years ago

See also PR #3776.

roed314 commented 4 years ago

And PR #3779.

rbommel commented 3 years ago

Is this issue resolved now?

AndrewVSutherland commented 3 years ago

None of HMF, BMF, ECNF provide an option to constrain primes dividing the conductor norm. Just adding a bad primes search option should automatically provide include/exclude/exactly/subset options.

JohnCremona commented 3 years ago

What these three have in common is that the primes in question are number field primes so it is not at all clear how a user might input them. Easier, though less good, would be for the database to include a list of prime numbers dividing the norm of the level / conductor. Then one could easily constrain these in a search.

AndrewVSutherland commented 3 years ago

@JohnCremona we discussed this at today's "LMFDB Friday" meeting I think the plan is to add options to constrain the primes dividing the level/conductor norm and the primes dividing the discriminant of the number field separately; both are integers, and the primes dividing the conductor of the L-function (also an integer) are the primes that divide the product of these, but we thought it would be more useful/flexible to let users constrain the level/conductor norm and field discriminant separately.

I believe @rbommel is working on this.

rbommel commented 3 years ago

Yes, after David finished checking my code to put the lists of bad primes in the tables, I will continue on this.

JohnCremona commented 3 years ago

Understood ! Please tell me the new column names and types so I can update my scripts for ECNF and BMF.

rbommel commented 3 years ago

My current idea was to have the columns 'field_bad_primes' and 'level_bad_primes' for BMF and HMF, and 'conductor_norm_factors' for ECNF. All of them are 'integer[]'. But nothing has been done so far, so feel free to make other suggestions for the names.

JohnCremona commented 3 years ago

For ECNF: there are columns 'n_bad_primes' (number of bad p), 'bad_primes' (list of strings only useful for display), and 'local_data' which is a list of dicts, one per bad prime, of which one key is 'normp'. So if C is an ECNF record then [ld['np'] for ld in C['local_data']] gives you the norms of the bad primes. I suppose that just factoring 'conductor_norm' is easier.

JohnCremona commented 3 years ago

For BMFs: there is only 'level_norm' in the databse. The script to display one BMF actually constructs the number field and the level as an ideal and factors it. Sorry about that. HMFs also (in hmf_forms) only has 'level_norm', and a text column for 'level_ideal'.

rbommel commented 3 years ago

See also pull request #4527.

JohnCremona commented 3 years ago

I see that ec_nfcurves has a new column 'conductor_norm_factors': 'integer[]'. I will revise my upload scripts so that new data uploaded fills this correctly. (Referring to #610 which mentions 55 missing curves over sextic fields, I now have 42 of them and so hop to fill those gaps before too long.)

rbommel commented 3 years ago

That is great, @JohnCremona, thank you very much!