Identifying coefficient fields on classical modular form pages

[AndrewVSutherland]

In cases where the coefficient field of a classical modular form is in the LMFDB we should identify it (this should be done in the database, not on the fly). In cases where it is not we should list the polredabs() of its defining polynomial so that it can be more easily identified (and if it later appears in the LMFDB, it will be easy for us to detect this). For example, the space

http://beta.lmfdb.org/ModularForm/GL2/Q/holomorphic/23/8/1/?group=0

has to Hecke orbits in it, one with coefficient field of degree 5 and the other of degree 8, with defining polynomials:

x^5 + 16x^4 - 320x^3 - 3136x^2 + 25680x + 10816
x^8 - 832x^6 - 1059x^5 + 203052x^4 + 678328x^3 - 13424272x^2 - 73308944x - 37372224

The second of these is actually equal to its polradabs (in Sage use pari(f).polredabs() to get it), but the first is not, its polredabs is instead

x^5 - 2x^4 - 104x^3 + 200x^2 + 2037x - 3704

Aside from usually being smaller to display, polredabs gives us a convenient way to identify number fields, and to find them in the LMFDB if they are present (neither of these two are, but I suspect there may be other cases where there are fields that are in the LMFDB but not identified as such, we should check).

The poly_to_field_label function in lmfdb/lmfdb/number_fields/number_field.py is currently used by the function field_label in lmfdb/lmfdb/modular_forms/elliptic_modular_forms/backend/emf_utils.py, but it does not appear that this has been done for every modular form (we do not want to be doing this on the fly, the coefficient field label should be stored in the database).

This issue is different from #654, which is about finding a basis for the coefficient field that makes the q-expansion coefficients more pleasing to look at.

[sehlen]

We don’t use the poly_to_field_label anymore but we do compute the lmfdb label at computing time and store it in the database.
It is never done on the fly (unless there is a bug) and I think we can remove it from emf_utils (I might have done it in my cleanup, I will check and otherwise do so).

Since this can sometimes take quite a while, we restricted ourselves to degree <=4, I think.
This can easily be changed and rerun.

On May 17, 2016, at 10:50, Andrew Sutherland notifications@github.com wrote:

In cases where the coefficient field of a classical modular form is in the LMFDB we should identify it (this should be done in the database, not on the fly). For example the coefficient field of 24.40.1.d on page

http://beta.lmfdb.org/ModularForm/GL2/Q/holomorphic/24/40/1/d/ http://beta.lmfdb.org/ModularForm/GL2/Q/holomorphic/24/40/1/d/
is currently identified by the minimal polynomial of one of its coefficients, which takes several lines to display, but in fact it is the number field http://www.lmfdb.org/NumberField/5.5.47500828.1 http://www.lmfdb.org/NumberField/5.5.47500828.1.

The poly_to_field_label function in lmfdb/lmfdb/number_fields/number_field.py is currently used by the function field_label in lmfdb/lmfdb/modular_forms/elliptic_modular_forms/backend/emf_utils.py, but it does not appear that this has been done for every modular form (we do not want to be doing this on the fly, the coefficient field label should be stored in the database).

This issue is different from #654 #654, which is about finding a basis for the coefficient field that makes the q-expansion coefficients more pleasing to look at.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #1386

[AndrewVSutherland]

@sehlen Great, we should definitely do this. If this is time consuming I can easily run it for you and just hand you a list of pairs (hecke_orbit_label, number_field_label). Would that be helpful?

[jwj61]

I have not read this whole thread, but thought I might be able to add something anyway.

The key to lookup in the number field database is polredabs. In modest degrees, it works great. In middle ranges, I often do something like the current polredbest first. Getting the coefficients down somewhat first definitely helps.

If you have polredabs, I would store the coefficients. Webnumberfield has a fast routine for looking up a number field based on a list of polredabs'ed coefficients (it queries the database using an indexed entry), and then you can get the label. You should not put the query in modular forms code since it has to hash the coefficients first, so we don't want to have this in more than one place.

The advantage of storing coefficients is that the lookup is fast, and if we add the number field later, your code will be getting the label back without rerunning any precomputations.

[AndrewVSutherland]

@jwj61 Right, I actually have a sage script running now that is attempting to polredabs the coefficient fields of all the coefficient fields that arise for levels N <=24 and weights 2 <= w <= 40 with trivial character. The degrees range up to 37, so not all of these will be in the LMFDB right now, but storing the coefficients is a great idea.

As we go further it will surely become infeasible to polredabs everything (e.g. Bober's degree 800 monster). You have a lot more experience with this than we do, can you suggest a reasonable degree (or discriminant) cutoff (i.e. a cutoff that might be beyond the range of the LMFDB now, but is still small enough to imagine that (a) polredabs takes less than, say, an hour (b) they might eventually be in the LMFDB)?

[sehlen]

@AndrewVSutherland Are you sure your example is correct? How did you identify it?
I changed our computing routine to not have an upper bound on the degree for now but a timeout of currently 3 minutes as we don't want to get stuck in computing the label. I can adjust that.
I'm getting a negative result as according to my computation the discriminant of the number field is

2^2 * 11 * 71 * 4588681 * 1127783798177 * 12598947569092757 * 6492845955349754347 * 306207477043391206303

What we do (following Nicholas Mascot) is essentially the following:
Instead of doing exact calculations, we first get a list of ramified and unramified primes <=200 and the signature. This gives a usually short list of candidates which we check using nfisisom. This seems to work rather nicely but maybe we have to adjust some parameters.

Storing polredabs is not a bad idea, though, I guess.

[sehlen]

@jwj61 Thanks for weighing in on this.
We had a longer discussion about this in December and Nicolas Mascot had some great ideas and illustrated how his function could be used to find an isomorphic number field that is in the db which we could then also use to simplify the coefficients of the Fourier expansion.
We haven't applied the second part of his method yet as it requires more testing and I'm not sure when it really gives better results. For your reference, so that you don't have to search the modforms-db code, I posted the function that we currently use here: https://gist.github.com/sehlen/f9b4655b215bd865cce929decdd14889

It is a bit complicated since it covers many cases and is intended to be called with a matrix and a vector that describe the Hecke eigenvalues (that's for rewriting them in terms of a new basis). But it can just be called with v=[a] and label_only=True, where a is a number field element and then it's supposed to return the number field label from the lmfdb. Please feel free to tell us that we shouldn't do this at all and what we should do instead if we just want the label. We were under the impression that this was faster in practice than calling poly_to_field_label or so because we can get a negative answer pretty quickly, which is currently the common situation.

[jwj61]

poly_to_field_label in the number field code simply calls from_polynomial in WebNumberField, which in turn calls polredabs. If you want to determine if a field is in the number field database at that instant, your approach sounds reasonable.

The approach I was suggesting has the advantage that you do the computation once, and then the only thing done on the fly is the database lookup. Moreover, it will pick up the addition of the field if it happens some time in the future, without any change from you.

I can almost always get a polredabs'ed polynomial in degree < 25 by using "prepolred" first (a function I wrote). I haven't tested, but polredbest may work as well (as a preliminary reduction), if not better.

As to bounds, we currently can't have anything of degree > 23. Even if we expand in the future, degree 31 would be a natural cutoff (there are many Galois groups in degree 32).

[AndrewVSutherland]

@sehlen (regarding #1386 (comment)) Apologies! That was due to a cut and paste error and you are absolutely right, that field is most definitely not in the LMFDB (nor likely to be any time soon!). I have updated my initial comment to give another (much less extreme) example which illustrates the same point.

Actually, in most of the cases I have looked at closely, the defining polynomials we are displaying on the classical modular forms pages actually look pretty good, but in many cases they are not the polredabs(). In cases where it is feasible to compute these (and thank you @jwj61 for the tips, this will definitely help!), we should try to do so.

[sehlen]

Well, @AndrewVSutherland, we could polredabs the polynomials but note that we currently do not just give any generator of the number field but of course the one appearing in the q-expansion. So just applying polredabs is not enough. The code that I shared does more, it changes the coefficients and that has to be done in one way or the other. But it is not clear at all that if we take a generator with minimal polynomial given by polredabs, that this gives nicer Fourier coefficients. They might become worse, no?

[sehlen]

Let me add that I have seen both cases when testing our routine.
Most of the time the coefficients seem to get better, at other times worse.

But I have an idea that might work in almost all of the cases, I just have to see why or get enough counterexamples:
We're in fact storing the output of the compact_system_of_eigenvalues method of the modular symbols space in sage. It consists of a matrix E and a vector v, such that E_v contains the Hecke eigenvalues of a newform (up to the number of rows in E), E has coordinates in the base_ring, that is QQ or a cyclotomic field if we have a non-triv char. of order >2 and v a basis of the coefficient field, you can imagine. Now, if the character is at most quadratic, i.e. the entires in E lie in Q, then it seems that these rational numbers have a far lower height than those that you would obtain from the corresponding power basis which we show now (wrt to the generator sage picked). So it seems that we should not even multiply E_v but instead could give the generators (well, they might be complicated, I agree) and then the Fourier expansion becomes suddenly readable. However, if the entries lie in a cyclotomic field, all the examples I looked at became better after multiplying E*v and using the output we currently show (in terms of the power basis sage picked). In this case however, the method posed above seems to work in many cases, so maybe we should apply it only here.

[JohnCremona]

@sehlen William and I came up with this method of storing E and v where the matrix E was potentially huge but the entries of v were much much smaller, instead of storing the product. That was in the early 2000s when he was still working in Magma or even possibly C++. As well as taking up far less storage space it enabled one to "see" the newforms much more compactly once the nasty change-of-basis matrix was out of the way.
I do have some code to do this, only for weight 2 and trivial character, and will attach the output for level 523 and the +1 eigenspace for W(523) which has dimension 17 and splits into 2+15. The a_p for p<1000 are given here for the 15-dimensional piece and you are supposed to notice how small they are (lists of 15 integers almost all of at most 2 digits) preceded by the change of basis matrix with denominator 242471 and numeratorsupt o 10 digits, giving the nice basis in terms of the power basis in alpha = T2-eigenvalue.
newform_523_2.txt

Any other nice examples I can try my code on? It takes a small number of seconds. The code is in eclib which you all have as it is in the Sage distribution ;)

[AndrewVSutherland]

So there are two separate issues here, both of which are worthy of discussion, but only one of which is directly relevant to the topic of this thread (issue #1386), which is about identifying the coefficient field of a classical modular form; this is an arithmetic invariant that anyone interested in the modular form might like to know, independent of how we choose to represent the coefficients (and it might even be of interest to people who don't care to look at the coefficients at all).

In the LMFDB we use a canonical defining polynomial to describe number fields (as explained in http://www.lmfdb.org/knowledge/show/nf.defining_polynomial.normalization); for number fields that are in the LMFDB we can and should use the number field label (possibly with a pretty print as noted elsewhere), but for number fields not in the LMFDB there is a strong argument to use this canonical polynomial to identify the number field (whether or not it is the minimal polynomial of any particular Fourier coefficient), at least if it is computationally feasible to compute it (and @jwj61 has helpfully given us some tips that should improve the range of "computationally feasible). This has the advantage of being canonical and readily computable by anyone with access to Pari (within the range of computational feasibility) and if we add the field to the LMFDB later it will make it easier to match (as noted by @jwj61).

@sehlen I agree that in some cases the polynomial returned by polredabs() is not always the most compact, but it has the advantage of being canonical and is usually very close to the most compact representation you are likely to find. Note that I am not saying we should necessarily choose to represent the q-expansion coefficients in terms of a root of the polredabs() polynomial; if there is another better choice of representation (of if @JohnCremona's suggestion makes sense), that's fine.

I'm also thinking of (what I expect will be many) cases where we choose not to display the q-expansion coefficients at all, but still can reasonably display a defining polynomial for the coefficient field.

[AndrewVSutherland]

@sehlen I'm working now on computing the polredabs() polynomial for all the coefficient fields that arise in the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to incorporate some of @jwj61's suggestions to speed it up. I'll let you know how it goes.

[sehlen]

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we have it and maybe it makes indeed sense to query the field at runtime instead of storing it but I always prefer stored solutions if it is very easy to update (and if we do have the polredabs, it is). But we could test, how fast the lookup really is and if it is virtually no delay, we could indeed look it up on the fly if polredabs has been computed.

On May 18, 2016, at 12:33, Andrew Sutherland notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the polredabs() polynomial for all the coefficient fields that arise in the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to incorporate some of @jwj61 https://github.com/jwj61's suggestions to speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #1386 (comment)

[AndrewVSutherland]

I think I would still store the LMFDB label when it is known. Since so
many of them will not be in the LMFDB it might make sense to always
display the polredabs poly for consistency (with a link to the number
field page when it is there).

On 2016-05-18 12:36, Stephan Ehlen wrote:

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we
have it and maybe it makes indeed sense to query the field at runtime
instead of storing it but I always prefer stored solutions if it is
very easy to update (and if we do have the polredabs, it is). But we
could test, how fast the lookup really is and if it is virtually no
delay, we could indeed look it up on the fly if polredabs has been
computed.

On May 18, 2016, at 12:33, Andrew Sutherland
notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the
polredabs() polynomial for all the coefficient fields that arise in
the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to
incorporate some of @jwj61 https://github.com/jwj61's suggestions to
speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)

[sehlen]

Well, I think it definitely makes sense to show the polynomial that is the minimal polynomial of the Fourier coefficients if they are shown.
That would mean, if we show them, you want to show two polynomials.
This could be ok.

I am close to finishing what I promised which will address many of the issues with classical modular forms but I have not found invested much time in improving the display of the polynomials on the page. Maybe someone with experience could later on help with that.
What I would like to have is that the polynomial displays in latex but can be copied and also displays nicely even if it is huge. I put it now inside of a div that’s scrollable but it’s not optimal and you still can’t copy it. I’ll mention this again when I issue the pull request/

On May 18, 2016, at 13:55, Andrew Sutherland notifications@github.com wrote:

I think I would still store the LMFDB label when it is known. Since so
many of them will not be in the LMFDB it might make sense to always
display the polredabs poly for consistency (with a link to the number
field page when it is there).

On 2016-05-18 12:36, Stephan Ehlen wrote:

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we
have it and maybe it makes indeed sense to query the field at runtime
instead of storing it but I always prefer stored solutions if it is
very easy to update (and if we do have the polredabs, it is). But we
could test, how fast the lookup really is and if it is virtually no
delay, we could indeed look it up on the fly if polredabs has been
computed.

On May 18, 2016, at 12:33, Andrew Sutherland
notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the
polredabs() polynomial for all the coefficient fields that arise in
the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to
incorporate some of @jwj61 https://github.com/jwj61's suggestions to
speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #1386 (comment)

[AndrewVSutherland]

On 2016-05-18 13:59, Stephan Ehlen wrote:

Well, I think it definitely makes sense to show the polynomial that is
the minimal polynomial of the Fourier coefficients if they are shown.
That would mean, if we show them, you want to show two polynomials.
This could be ok.

Yes, in cases where we display the q-expansions we will want both. In
cases where we do not we would only display the defining polynomial for
the number field.

One suggestion would be to remove the q-expansions from the page for the
space and only put it on the form page. I realize that for the low
level/weight examples its nice to see the q-expansion (especially over
Q), but for the higher level/weight spaces (which will eventually mean
almost all of them), its awkward to display them and makes the pages
very slow to load (especially painful if someone is just browsing by
clicking around on spaces to see whats there).

Another option would be to list just a little information about the
coefficients, e.g. the traces of the first few, perhaps in a table (of
course for the forms over Q this would be the coefficients themselves).

I am close to finishing what I promised which will address many of the
issues with classical modular forms but I have not found invested much
time in improving the display of the polynomials on the page. Maybe
someone with experience could later on help with that.
What I would like to have is that the polynomial displays in latex but
can be copied and also displays nicely even if it is huge. I put it
now inside of a div that’s scrollable but it’s not optimal and you
still can’t copy it. I’ll mention this again when I issue the pull
request/

You want "Show commands using sage, pari/gp, magma" option at the top of
the page, like we have elsewhere, e.g.

http://www.lmfdb.org/EllipticCurve/Q/11/a/1
http://www.lmfdb.org/NumberField/5.1.1609.1
http://www.lmfdb.org/Genus2Curve/Q/249/a/6723/1

There is standard code for doing this (I can add this if you like).

On May 18, 2016, at 13:55, Andrew Sutherland
notifications@github.com wrote:

I think I would still store the LMFDB label when it is known. Since so
many of them will not be in the LMFDB it might make sense to always
display the polredabs poly for consistency (with a link to the number
field page when it is there).

On 2016-05-18 12:36, Stephan Ehlen wrote:

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we
have it and maybe it makes indeed sense to query the field at runtime
instead of storing it but I always prefer stored solutions if it is
very easy to update (and if we do have the polredabs, it is). But we
could test, how fast the lookup really is and if it is virtually no
delay, we could indeed look it up on the fly if polredabs has been
computed.

On May 18, 2016, at 12:33, Andrew Sutherland
notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the
polredabs() polynomial for all the coefficient fields that arise in
the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to
incorporate some of @jwj61 https://github.com/jwj61's suggestions to
speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)

[sehlen]

On May 18, 2016, at 14:13, Andrew Sutherland notifications@github.com wrote:

On 2016-05-18 13:59, Stephan Ehlen wrote:

Well, I think it definitely makes sense to show the polynomial that is
the minimal polynomial of the Fourier coefficients if they are shown.
That would mean, if we show them, you want to show two polynomials.
This could be ok.

Yes, in cases where we display the q-expansions we will want both. In
cases where we do not we would only display the defining polynomial for
the number field.

One suggestion would be to remove the q-expansions from the page for the
space and only put it on the form page. I realize that for the low
level/weight examples its nice to see the q-expansion (especially over
Q), but for the higher level/weight spaces (which will eventually mean
almost all of them), its awkward to display them and makes the pages
very slow to load (especially painful if someone is just browsing by
clicking around on spaces to see whats there).

All fixed in my new branch, as I said, pull request is coming up but I need to improve it a bit further and test it more.
Nothing will be slow to load anymore although I’m very flexible in discussing how this should be displayed exactly.
Right now I sticked to the current layout and I’m just hiding the q-expansions individually that have too “complicated” coefficients using a stupid heuristic.

Another option would be to list just a little information about the
coefficients, e.g. the traces of the first few, perhaps in a table (of
course for the forms over Q this would be the coefficients themselves).

Good idea, we should look into that later.

I am close to finishing what I promised which will address many of the
issues with classical modular forms but I have not found invested much
time in improving the display of the polynomials on the page. Maybe
someone with experience could later on help with that.
What I would like to have is that the polynomial displays in latex but
can be copied and also displays nicely even if it is huge. I put it
now inside of a div that’s scrollable but it’s not optimal and you
still can’t copy it. I’ll mention this again when I issue the pull
request/

You want "Show commands using sage, pari/gp, magma" option at the top of
the page, like we have elsewhere, e.g.

http://www.lmfdb.org/EllipticCurve/Q/11/a/1
http://www.lmfdb.org/NumberField/5.1.1609.1
http://www.lmfdb.org/Genus2Curve/Q/249/a/6723/1

There is standard code for doing this (I can add this if you like).

I know. Please don’t add it right now because we will have conflicts.

On May 18, 2016, at 13:55, Andrew Sutherland
notifications@github.com wrote:

I think I would still store the LMFDB label when it is known. Since so
many of them will not be in the LMFDB it might make sense to always
display the polredabs poly for consistency (with a link to the number
field page when it is there).

On 2016-05-18 12:36, Stephan Ehlen wrote:

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we
have it and maybe it makes indeed sense to query the field at runtime
instead of storing it but I always prefer stored solutions if it is
very easy to update (and if we do have the polredabs, it is). But we
could test, how fast the lookup really is and if it is virtually no
delay, we could indeed look it up on the fly if polredabs has been
computed.

On May 18, 2016, at 12:33, Andrew Sutherland
notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the
polredabs() polynomial for all the coefficient fields that arise in
the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to
incorporate some of @jwj61 https://github.com/jwj61's suggestions to
speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #1386 (comment)

[AndrewVSutherland]

@sehlen No worries, I won't touch the code until you are finished and
your pull request is merged.

On 2016-05-18 14:17, Stephan Ehlen wrote:

On May 18, 2016, at 14:13, Andrew Sutherland
notifications@github.com wrote:

On 2016-05-18 13:59, Stephan Ehlen wrote:

Well, I think it definitely makes sense to show the polynomial that is
the minimal polynomial of the Fourier coefficients if they are shown.
That would mean, if we show them, you want to show two polynomials.
This could be ok.

Yes, in cases where we display the q-expansions we will want both. In
cases where we do not we would only display the defining polynomial
for
the number field.

One suggestion would be to remove the q-expansions from the page for
the
space and only put it on the form page. I realize that for the low
level/weight examples its nice to see the q-expansion (especially over
Q), but for the higher level/weight spaces (which will eventually mean
almost all of them), its awkward to display them and makes the pages
very slow to load (especially painful if someone is just browsing by
clicking around on spaces to see whats there).

All fixed in my new branch, as I said, pull request is coming up but I
need to improve it a bit further and test it more.
Nothing will be slow to load anymore although I’m very flexible in
discussing how this should be displayed exactly.
Right now I sticked to the current layout and I’m just hiding the
q-expansions individually that have too “complicated” coefficients
using a stupid heuristic.

Another option would be to list just a little information about the
coefficients, e.g. the traces of the first few, perhaps in a table (of
course for the forms over Q this would be the coefficients
themselves).

Good idea, we should look into that later.

I am close to finishing what I promised which will address many of the
issues with classical modular forms but I have not found invested much
time in improving the display of the polynomials on the page. Maybe
someone with experience could later on help with that.
What I would like to have is that the polynomial displays in latex but
can be copied and also displays nicely even if it is huge. I put it
now inside of a div that’s scrollable but it’s not optimal and you
still can’t copy it. I’ll mention this again when I issue the pull
request/

You want "Show commands using sage, pari/gp, magma" option at the top
of
the page, like we have elsewhere, e.g.

http://www.lmfdb.org/EllipticCurve/Q/11/a/1
http://www.lmfdb.org/NumberField/5.1.1609.1
http://www.lmfdb.org/Genus2Curve/Q/249/a/6723/1

There is standard code for doing this (I can add this if you like).

I know. Please don’t add it right now because we will have conflicts.

On May 18, 2016, at 13:55, Andrew Sutherland
notifications@github.com wrote:

I think I would still store the LMFDB label when it is known. Since so
many of them will not be in the LMFDB it might make sense to always
display the polredabs poly for consistency (with a link to the number
field page when it is there).

On 2016-05-18 12:36, Stephan Ehlen wrote:

@AndrewVSutherland
Very good, we can add this as an additional field to the db, then we
have it and maybe it makes indeed sense to query the field at runtime
instead of storing it but I always prefer stored solutions if it is
very easy to update (and if we do have the polredabs, it is). But we
could test, how fast the lookup really is and if it is virtually no
delay, we could indeed look it up on the fly if polredabs has been
computed.

On May 18, 2016, at 12:33, Andrew Sutherland
notifications@github.com wrote:

@sehlen https://github.com/sehlen I'm working now on computing the
polredabs() polynomial for all the coefficient fields that arise in
the 1<= N <= 24, 2<=w<=40 box with trivial character, but I want to
incorporate some of @jwj61 https://github.com/jwj61's suggestions to
speed it up. I'll let you know how it goes.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)

[sehlen]

I'm getting closer to issuing a pull request but I'm asking for some feedback and maybe some help because I don't have the time to worry so much about html/css issues right now and maybe someone else is faster at this. The following screenshot is a nice example of what can happen and how the pages will look after my updates (many things happened in the background but this is one of the visible things).

(There are no knowls on the page because it is served from my own mongo instance which doesn't contain knowls)

What I would like is that:

1. The whitespace on top of the page is avoided
2. The minimal polynomials occupy each only one line
3. they become scrollable so that you can see everything if you want
4. and you can copy/paste them

If you want to take a look, check out my branch https://github.com/sehlen/lmfdb/tree/cleanup_bugfix_efficiency
which I will still work on for a little while and then squash some of the very frequent commits before I issue a pull request.

The template used here is https://github.com/sehlen/lmfdb/blob/cleanup_bugfix_efficiency/lmfdb/modular_forms/elliptic_modular_forms/views/templates/emf_web_modform_space.html which includes https://github.com/sehlen/lmfdb/blob/cleanup_bugfix_efficiency/lmfdb/modular_forms/elliptic_modular_forms/views/templates/display-list-newforms.html.

The same issues essentially apply to the page of a single form.

[fredstro]

That looks good :)
How would you like the whitespace avoided?
Having line-breaks for the polynomials or having them appear behind the box?
I guess they could be made to move up and down when the box is opened and closed….

On 18 May 2016, at 20:48, Stephan Ehlen notifications@github.com wrote:

I'm getting closer to issuing a pull request but I'm asking for some feedback and maybe some help because I don't have the time to worry so much about html/css issues right now and maybe someone else is faster at this. The following screenshot is a nice example of what can happen and how the pages will look after my updates (many things happened in the background but this is one of the visible things).

(There are no knowls on the page because it is served from my own mongo instance which doesn't contain knowls)
What I would like is that:

1. The whitespace on top of the page is avoided

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #1386 (comment)

[sehlen]

I thought it would make sense to either truncate them dynamically or to put them in a div that’s scrollable.
I did this with the minimal polynomial here:

http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/ http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/

(only online now might be offline later)

On May 18, 2016, at 15:53, Fredrik Strömberg notifications@github.com wrote:

That looks good :)
How would you like the whitespace avoided?
Having line-breaks for the polynomials or having them appear behind the box?
I guess they could be made to move up and down when the box is opened and closed….

On 18 May 2016, at 20:48, Stephan Ehlen notifications@github.com wrote:

I'm getting closer to issuing a pull request but I'm asking for some feedback and maybe some help because I don't have the time to worry so much about html/css issues right now and maybe someone else is faster at this. The following screenshot is a nice example of what can happen and how the pages will look after my updates (many things happened in the background but this is one of the visible things).

(There are no knowls on the page because it is served from my own mongo instance which doesn't contain knowls)
What I would like is that:

1. The whitespace on top of the page is avoided

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #1386 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #1386 (comment)

[davidfarmer]

There are a few pages where things go below the properties box.

Not sure if the horixontal scroll would work as well in this
case, because it is a table, not just one big formula.

I suggest leaving it as-is, and submitting an issue.

On Wed, 18 May 2016, Stephan Ehlen wrote:

I thought it would make sense to either truncate them dynamically or to put them in a div that’s
scrollable.
I did this with the minimal polynomial here:

http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/
http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/

(only online now might be offline later)

On May 18, 2016, at 15:53, Fredrik Strömberg notifications@github.com wrote:

That looks good :)
How would you like the whitespace avoided?
Having line-breaks for the polynomials or having them appear behind the box?
I guess they could be made to move up and down when the box is opened and closed….

On 18 May 2016, at 20:48, Stephan Ehlen notifications@github.com wrote:

I'm getting closer to issuing a pull request but I'm asking for some feedback and maybe some help
because I don't have the time to worry so much about html/css issues right now and maybe someone else
is faster at this. The following screenshot is a nice example of what can happen and how the pages
will look after my updates (many things happened in the background but this is one of the visible
things).

(There are no knowls on the page because it is served from my own mongo instance which doesn't
contain knowls)
What I would like is that:

1. The whitespace on top of the page is avoided

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1386 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
GitHub[AAM6LEY2YS4Lpk1RcsqiFrAJsJFXjYMOks5qC3QWgaJpZM4IgXBt.gif]

[AndrewVSutherland]

Not directly related to what you are working on, but I would put more in
the properties box (label, level, weight, character, dimension, ...),
see http://www.lmfdb.org/EllipticCurve/Q/11/a/1 or
http://www.lmfdb.org/Genus2Curve/Q/169/a/169/1, for example (obviously
you don't have a picture to display (yet!)).

But feel free to hold off on this, I can fiddle with it after you submit
your pull request if you like.

On 2016-05-18 16:18, Stephan Ehlen wrote:

I thought it would make sense to either truncate them dynamically or
to put them in a div that’s scrollable.
I did this with the minimal polynomial here:

http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/
http://130.211.5.157/ModularForm/GL2/Q/holomorphic/92/10/91/c/

(only online now might be offline later)

On May 18, 2016, at 15:53, Fredrik Strömberg
notifications@github.com wrote:

That looks good :)
How would you like the whitespace avoided?
Having line-breaks for the polynomials or having them appear behind
the box?
I guess they could be made to move up and down when the box is opened
and closed….

On 18 May 2016, at 20:48, Stephan Ehlen notifications@github.com wrote:

I'm getting closer to issuing a pull request but I'm asking for some feedback and maybe some help because I don't have the time to worry so much about html/css issues right now and maybe someone else is faster at this. The following screenshot is a nice example of what can happen and how the pages will look after my updates (many things happened in the background but this is one of the visible things).

(There are no knowls on the page because it is served from my own mongo instance which doesn't contain knowls)
What I would like is that:

1. The whitespace on top of the page is avoided

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #1386 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1386 (comment)

[AndrewVSutherland]

@jwj61 So I have been using polredbest(), but polredabs() is still struggling with many of the polynomials, is there any chance you could make your prepolred() function available?

[jwj61]

prepolred(pol)=
{
local(pr, ml2, ans,tmp,orig);
pr = polred(pol,1);
ans=[];
orig=norml2(polroots(pol));
for(j=1,#pr, if(poldegree(pr[j]) == poldegree(pol), ans=concat(ans,[pr[j]])));
if(#ans==0, print("prepolred found none");return(pol));
pr=ans;
ml2= norml2(polroots(pr[1])); ans = pr[1];
for(j=2,#pr,
tmp=norml2(polroots(pr[j]));
if(tmp<ml2, ml2=tmp; ans=pr[j]));
if(ml2>orig, ans=pol);
return(ans);
}

It goes through the output of polred and picks one of the same degree, and then picks the one with minimal L_2 norm on the roots. Now that I know more about polred, it should be the first one of the correct degree.

[AndrewVSutherland]

@jwj61 Thanks!

[AndrewVSutherland]

After pouring a fair bit of computational resource at this problem, I've come to the conclusion that in general it is not going to be feasible to compute polredabs() polynomials for all the fields we would like to; the problem is that even if we ignore the higher degree cases (say degree >= 32, or even >=16), the problem is that so many of the fields have very large discriminants, and this makes polredabs() very expensive (even when preceded by polredbest or prepolred); in fact just computing the discriminant can be prohibitevely expensive.

So until/unless someone else comes up with a better idea, I'm going to go ahead and close this issue, and instead suggest that we should just attempt to identify all the fields that are actually in the LMFDB whenever possible, which is essentially what we are doing now. We can probably work a bit harder than we currently are (I believe at the moment we are only checking fields of degree <= 4), but so far I haven't found any fields of degree > 4 that arise as coefficient fields of modular forms that are also in the LMFDB; the discriminants are typically much too large.

[sehlen]

On May 20, 2016, at 18:58, Andrew Sutherland notifications@github.com wrote:

After pouring a fair bit of computational resource at this problem, I've come to the conclusion that in general it is not going to be feasible to compute polredabs() polynomials for all the fields we would like to; the problem is that even if we ignore the higher degree cases (say degree >= 32, or even >=16), the problem is that so many of the fields have very large discriminants, and this makes polredabs() very expensive (even when preceded by polredbest or prepolred); in fact just computing the discriminant can be prohibitevely expensive.

That’s what I remembered from trying quite a while ago and that’s more or less why we ended up doing what we do now.
But it is very good that you tried!

So until/unless someone else comes up with a better idea, I'm going to go ahead and close this issue, and instead suggest that we should just attempt to identify all the fields that are actually in the LMFDB whenever possible, which is essentially what we are doing now. We can probably work a bit harder than we currently are (I believe at the moment we are only checking fields of degree <= 4), but so far I haven't found any fields of degree > 4 that arise as coefficient fields of modular forms that are also in the LMFDB; the discriminants are typically much too large.

We used the cutoff degree <= 4 for a while because experience showed that it would usually work for those and also return a negative result if no match was found. I changed this into a timeout instead but I guess you’re right that we can still cut off at some point and not waste 3 minutes of computing time for each newform where the degree is >16, say.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #1386 (comment)

[AndrewVSutherland]

On 2016-05-20 19:44, Stephan Ehlen wrote:

On May 20, 2016, at 18:58, Andrew Sutherland
notifications@github.com wrote:

After pouring a fair bit of computational resource at this problem,
I've come to the conclusion that in general it is not going to be
feasible to compute polredabs() polynomials for all the fields we
would like to; the problem is that even if we ignore the higher degree
cases (say degree >= 32, or even >=16), the problem is that so many of
the fields have very large discriminants, and this makes polredabs()
very expensive (even when preceded by polredbest or prepolred); in
fact just computing the discriminant can be prohibitevely expensive.

That’s what I remembered from trying quite a while ago and that’s more
or less why we ended up doing what we do now.
But it is very good that you tried!

So until/unless someone else comes up with a better idea, I'm going to
go ahead and close this issue, and instead suggest that we should just
attempt to identify all the fields that are actually in the LMFDB
whenever possible, which is essentially what we are doing now. We can
probably work a bit harder than we currently are (I believe at the
moment we are only checking fields of degree <= 4), but so far I
haven't found any fields of degree > 4 that arise as coefficient
fields of modular forms that are also in the LMFDB; the discriminants
are typically much too large.

We used the cutoff degree <= 4 for a while because experience showed
that it would usually work for those and also return a negative result
if no match was found. I changed this into a timeout instead but I
guess you’re right that we can still cut off at some point and not
waste 3 minutes of computing time for each newform where the degree is

16, say.

I like the idea of using a timeout plus an absolute cutoff. Just be
sure to call polredbest() first before calling polredabs(), otherwise it
is very easy to hit the timeout. If f in R.=QQ[] is a Sage
polynomial, we want

R(pari(f).polredbest().polredabs())

Currently WebNumberField does not do this, it just calls polredabs().

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1386 (comment)

---

You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
#1386 (comment)