Fix errors in classical modular form data and verify its correctness

[AndrewVSutherland]

In the thread for critical issue https://github.com/LMFDB/lmfdb/issues/1223 (errors in modular form data), it was suggested that we should hide the spaces with non-trivial character. This has not yet been done, and there are still many spaces with non-trivial character that have some but not all Hecke orbits missing. For example:

http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/11/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/13/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/3/97/2/

and many more (I will post an update version of emf_db_stats.py shortly that finds all these (now in merged pull request https://github.com/LMFDB/lmfdb/pull/1249).

We need to decide (within the next 12 hours!) whether to hide these spaces or not.

[AndrewVSutherland]

I note that in some cases we are still clearly displaying incorrect information (not just noting that a particular Hecke orbit is unavailable). For example, on the page

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/

we claim that the dimension of 61.2.48 is 5, but on

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/48/

the dimesions of the Hecke orbits sum to 8.

Similar problems can be found at

www.lmfdb.org/ModularForm/GL2/Q/holomorphic/57/2/4/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/31/2/16/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/55/4/26/

This incorrect information needs to either be fixed or hidden within the next 12 hours. The simplest fix would be to hide all spaces with non-trivial character.

[sehlen]

The first one is fixed, the others follow soon.

Trivial character is by now way more complete and non-trivial character should be a bit better but I focused on the trivial character. Once that is rock solid, we can head to non-trivial character but we won’t make a lot of progress in the next 10 hours or so. However, the re-insertion of the data works in general without a problem except for replication timeouts that are annoying. So, I think we can show non-trivial characters in a reasonable range but it might get a bit later than your deadline.

On May 9, 2016, at 03:02, AndrewVSutherland notifications@github.com wrote:

I note that in some cases we are still clearly displaying incorrect information (not just noting that a particular Hecke orbit is unavailable). For example, on the page

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/ we claim that the dimension of 61.2.48 is 5, but on

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/48/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/48/ the dimesions of the Hecke orbits sum to 8.

Similar problems can be found at

www.lmfdb.org/ModularForm/GL2/Q/holomorphic/57/2/4/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/57/2/4/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/31/2/16/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/31/2/16/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/55/4/26/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/55/4/26/ This incorrect information needs to either be fixed or hidden within the next 12 hours. The simplest fix would be to hide all spaces with non-trivial character.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217824683

[fredstro]

On 9 May 2016, at 11:02, AndrewVSutherland notifications@github.com wrote:

I note that in some cases we are still clearly displaying incorrect information (not just noting that a particular Hecke orbit is unavailable). For example, on the page

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/ we claim that the dimension of 61.2.48 is 5, but on

http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/48/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/61/2/48/ the dimesions of the Hecke orbits sum to 8.

Similar problems can be found at

www.lmfdb.org/ModularForm/GL2/Q/holomorphic/57/2/4/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/57/2/4/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/31/2/16/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/31/2/16/ www.lmfdb.org/ModularForm/GL2/Q/holomorphic/55/4/26/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/55/4/26/ This incorrect information needs to either be fixed or hidden within the next 12 hours. The simplest fix would be to hide all spaces with non-trivial character.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217824683

I fixed these instances. Please let me know if you find anything else: At the moment: 61.2.48 is ok 57.2.4 is ok 31.2.16 is ok. 55.4.26 is ok.

[AndrewVSutherland]

Below is a list of labels of spaces that have some but not all of the Hecke orbits they should. I do not know if these are all reachable, but for each we should either (a) verify that there is no way to navigate to the page or (b) add the missing Hecke orbits, or (c) remove the Hecke orbits that are there (which I understand will ensure that no link to the page listing the Hecke orbits will appear).

Hecke orbit data in webnewforms for space 57.2.8 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.8.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 56.10.27 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.11.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.13.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.97.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.19.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 23.11.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.9.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.25.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.31.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.37.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 55.2.34 is incomplete or inconsistent Hecke orbit data in webnewforms for space 92.10.91 is incomplete or inconsistent Hecke orbit data in webnewforms for space 63.2.17 is incomplete or inconsistent Hecke orbit data in webnewforms for space 25.12.24 is incomplete or inconsistent Hecke orbit data in webnewforms for space 27.7.26 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.49.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.17.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.67.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.79.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.73.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 20.15.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.4.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.7.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 31.3.30 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.9.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 20.7.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 20.19.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 91.7.90 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.15.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 30.8.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 7.13.6 is incomplete or inconsistent Hecke orbit data in webnewforms for space 7.15.6 is incomplete or inconsistent Hecke orbit data in webnewforms for space 31.5.30 is incomplete or inconsistent Hecke orbit data in webnewforms for space 30.10.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 30.12.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 19.3.18 is incomplete or inconsistent Hecke orbit data in webnewforms for space 63.2.20 is incomplete or inconsistent Hecke orbit data in webnewforms for space 63.2.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 51.4.43 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.61.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.7.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 20.11.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 23.7.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 30.6.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 7.17.6 is incomplete or inconsistent Hecke orbit data in webnewforms for space 55.11.54 is incomplete or inconsistent Hecke orbit data in webnewforms for space 7.19.6 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.85.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.91.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.10.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 90.3.37 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.5.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.6.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.11.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.11.17 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.12.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 23.9.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 52.4.17 is incomplete or inconsistent Hecke orbit data in webnewforms for space 62.2.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 55.4.34 is incomplete or inconsistent Hecke orbit data in webnewforms for space 25.10.24 is incomplete or inconsistent Hecke orbit data in webnewforms for space 56.11.13 is incomplete or inconsistent Hecke orbit data in webnewforms for space 24.3.5 is incomplete or inconsistent

[fredstro]

I am going through the output from emf_db_dtats.py (thanks a lot for that file!) as quick as I can but I have to do it all one by one since as soon as I try to parallelise or even make a loop over problematic labels I get the mongo error “waiting for replica sets” which (as discovered last week) might lead to corrupt gridfs records… If someone with the correct authorisation on the serves could figure out how to change the timeout settings for that it would be great (it appears I don’t have permissions to do it)

Fredrik

On 9 May 2016, at 10:50, AndrewVSutherland notifications@github.com wrote:

In the thread for critical issue #1223 https://github.com/LMFDB/lmfdb/issues/1223 (errors in modular form data), it was suggested that we should hide the spaces with non-trivial character. This has not yet been done, and there are still many spaces with non-trivial character that have some but not all Hecke orbits missing. For example:

http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/11/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/11/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/13/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/11/13/10/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/3/97/2/ http://lmfdb.warwick.ac.uk/ModularForm/GL2/Q/holomorphic/3/97/2/ and many more (I will post an update version of emf_db_stats.py shortly that finds all these.

We need to decide (within the next 12 hours!) whether to hide these spaces or not.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248

[AndrewVSutherland]

@fredstro, @sehlen You can easily regenerate the list above whenever you wish by running https://github.com/LMFDB/lmfdb/blob/master/lmfdb/modular_forms/elliptic_modular_forms/emf_db_stats.py (but be sure to do it on Atkin, it will be hopelessly slow if you run it locally).

I should note that all it is doing is checking for the existence of orbits and summing dimensions. It does not look at the data at all, and it does not guarantee that the dimensions are even correct. For example, when you fixed 61/2/48 you corrected 4+4=5 to 1+4=5. But there could very well be other cases where the decomposition is currently 2+3=5 but should be 1+4=5 and emf_db_stats.py will not detect this.

This makes me very nervous. Do we have any automated way to verify that at least the dimensions of the decomposition of the spaces are all correct?

Are we really confident that all this data is ready to be officially made public (in T-minus 10 hours)? This isn't meant as a criticism, I know you guys are working as hard and as fast as you can. I'm just asking the question (and I hope you and others who know more about this than I do will weigh in with an opinion).

[fredstro]

As far as I can think of there is only one way to do this and that is to use the decompositions in the database where they are stored as the Hecke modules given by sage. This is in the collection: modularforms2.Newform_factors.files' and the associated gridfs files. If we make sure to also check that the characters match (i.e. look at the values of generators) then this should give a correct value to compare with.

On 9 May 2016, at 13:59, AndrewVSutherland notifications@github.com wrote:

@fredstro https://github.com/fredstro, @sehlen https://github.com/sehlen You can easily regenerate the list above whenever you wish by running https://github.com/LMFDB/lmfdb/blob/master/lmfdb/modular_forms/elliptic_modular_forms/emf_db_stats.py https://github.com/LMFDB/lmfdb/blob/master/lmfdb/modular_forms/elliptic_modular_forms/emf_db_stats.py (but be sure to do it on Atkin, it will be hopelessly slow if you run it locally).

I should note that all it is doing is checking that all it is doing is checking for the existence of orbits and summing dimensions. It does not look at the data at all, and it does not guarantee that the dimensions are even correct. For example, when you fixed 61/2/48 you corrected 4+4=5 to 1+4=5. But there could very well be other cases where the decomposition is currently 2+3=5 but should be 1+4=5 and emf_db_stats.py will not detect this.

This makes me very nervous. Do we have any automated way to verify that at least the dimensions of the decomposition of the spaces are all correct?

Are we really confident that all this data is ready to be officially made public (in T-minus 10 hours)? This isn't meant as a criticism, I know you guys are working as hard and as fast as you can. I'm just asking the question (and I hope you and others who know more about this than I do will weigh in with an opinion).

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217857173

[davidfarmer]

I speculate that

The expected value of the criticism for not having Gamma_1(N) modular forms (i.e., nontrivial character)

is much greater than

The chance that someone stumbles on one of the spaces which have an issue.

plus

The chance that someone outside of us writes a script which finds those errors before they are fixed.

And so I don't think it is a good idea to hide the forms with character.

And my calculation does not even take into account the fact that Fredrik and Stephan have done an incredible job at a nearly thankless and very difficult task.

[AndrewVSutherland]

@davidfarmer Thanks for weighing in, that is all I wanted to know. Let's focus on fixing everything we can. Is there anyone who can help Fredrik and Stephan by, for example, running the verification he suggested above? This may very well find issues that emf_db_stats.py will miss.

At the moment I'm trying to figure out why ecnf searches by conductor norm are not working (https://github.com/LMFDB/lmfdb/issues/1250), although I'm sure @JohnCremona can help as soon as he comes online.

[davidfarmer]

The comments seem to make it clear that there are a tractable number of problems and Fredrik and Stephan have the tools to fix them, so I am going to change the title of the issue to

"Fix classical modular forms with non-trivial character for 1.0"

[AndrewVSutherland]

@davidfarmer Sounds good. And #1250 is now understood and easy to fix, so I can also help with data verification.

[jwbober]

I am tempted to interpret David's comment as "It is ok if the data is wrong, because no one will know." That's not the sort of reputation the LMFDB should be aiming for.

(I will report back later and try to be more helpful.)

[jwbober]

Here is a file with a list of 301 forms with possible errors in the prime coefficients: errors_1_399_primecoeffs.txt

(This covers weight <= 12 and level < 100, and weight <= 4 and level < 400).

For many of the forms with high weight, the problem may just be that the embedding hasn't been computed precisely enough. For example, the form 13.11.2.a, which is first on that list, looks like it may be correct, except that the embeddings are way off.

On the other hand, one of the forms early in that list is 15.5.11.a, which is obviously wrong because it doesn't even have the right dimension.

Here is a list of 1655 questionable forms if I include composite index coefficients in my comparison: errors_1_399_allcoeffs.txt

If I could get the embeddings of all of the coefficients of all of the forms to enough precision, I could run a better comparison, but grabbing and computing that might take more time than I have before tomorrow. So I don't know right now how many of the errors are due to a lack of precision and how many are due to worse errors. Also, I'm still using data I downloaded a few days ago, so some of it might have been fixed.

Last I checked, there were somewhere between 6000 and 7000 modular forms in the database. So I consider about 25% of the forms questionable, not taking into account the incomplete/inconsistent spaces that Drew has identified.

[fredstro]

On 9 May 2016, at 18:49, Jonathan Bober notifications@github.com wrote:

Here is a file with a list of 301 forms with possible errors in the prime coefficients: errors_1_399_primecoeffs.txt https://github.com/LMFDB/lmfdb/files/255502/errors_1_399_primecoeffs.txt (This covers weight <= 12 and level < 100, and weight <= 4 and level < 400).

For many of the forms with high weight, the problem may just be that the embedding hasn't been computed precisely enough. For example, the form 13.11.2.a, which is first on that list, looks like it may be correct, except that the embeddings are way off.

On the other hand, one of the forms early in that list is 15.5.11.a, which is obviously wrong because it doesn't even have the right dimension.

Here is a list of 1655 questionable forms if I include composite index coefficients in my comparison: errors_1_399_allcoeffs.txt https://github.com/LMFDB/lmfdb/files/255503/errors_1_399_allcoeffs.txt If I could get the embeddings of all of the coefficients of all of the forms to enough precision, I could run a better comparison, but grabbing and computing that might take more time than I have before tomorrow. So I don't know right now how many of the errors are due to a lack of precision and how many are due to worse errors. Also, I'm still using data I downloaded a few days ago, so some of it might have been fixed.

Last I checked, there were somewhere between 6000 and 7000 modular forms in the database. So I consider about 25% of the forms questionable, not taking into account the incomplete/inconsistent spaces that Drew has identified.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217937182 What should the dimension be for 15.5.11.a? Unless Stephan just recomputed it (which might of course have happened) it appears as dimension 6 on the webpage which is the same as sage gives.

Fredrik

[sehlen]

On May 9, 2016, at 10:49, Jonathan Bober notifications@github.com wrote:

Here is a file with a list of 301 forms with possible errors in the prime coefficients: errors_1_399_primecoeffs.txt https://github.com/LMFDB/lmfdb/files/255502/errors_1_399_primecoeffs.txt

How up-to-date is this data now? When did you run it?

Can we take the few ones with trivial character for now as a test case so that I can understand what’s going on? Can you give me some specifics on which coefficients fail for you for 29.4.1.a?

Non-trivial characters have not been dealt with extensively in our fixing so I would first like to get the trivial completely and undoubtably correct and then deal with the non-trivial characters.

(This covers weight <= 12 and level < 100, and weight <= 4 and level < 400).

For many of the forms with high weight, the problem may just be that the embedding hasn't been computed precisely enough. For example, the form 13.11.2.a, which is first on that list, looks like it may be correct, except that the embeddings are way off.

On the other hand, one of the forms early in that list is 15.5.11.a, which is obviously wrong because it doesn't even have the right dimension.

Here is a list of 1655 questionable forms if I include composite index coefficients in my comparison: errors_1_399_allcoeffs.txt https://github.com/LMFDB/lmfdb/files/255503/errors_1_399_allcoeffs.txt If I could get the embeddings of all of the coefficients of all of the forms to enough precision, I could run a better comparison, but grabbing and computing that might take more time than I have before tomorrow. So I don't know right now how many of the errors are due to a lack of precision and how many are due to worse errors. Also, I'm still using data I downloaded a few days ago, so some of it might have been fixed.

Last I checked, there were somewhere between 6000 and 7000 modular forms in the database. So I consider about 25% of the forms questionable, not taking into account the incomplete/inconsistent spaces that Drew has identified.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217937182

[sehlen]

On May 9, 2016, at 10:56, Fredrik Strömberg notifications@github.com wrote:

On 9 May 2016, at 18:49, Jonathan Bober notifications@github.com wrote:

Here is a file with a list of 301 forms with possible errors in the prime coefficients: errors_1_399_primecoeffs.txt https://github.com/LMFDB/lmfdb/files/255502/errors_1_399_primecoeffs.txt (This covers weight <= 12 and level < 100, and weight <= 4 and level < 400).

For many of the forms with high weight, the problem may just be that the embedding hasn't been computed precisely enough. For example, the form 13.11.2.a, which is first on that list, looks like it may be correct, except that the embeddings are way off.

On the other hand, one of the forms early in that list is 15.5.11.a, which is obviously wrong because it doesn't even have the right dimension.

Here is a list of 1655 questionable forms if I include composite index coefficients in my comparison: errors_1_399_allcoeffs.txt https://github.com/LMFDB/lmfdb/files/255503/errors_1_399_allcoeffs.txt If I could get the embeddings of all of the coefficients of all of the forms to enough precision, I could run a better comparison, but grabbing and computing that might take more time than I have before tomorrow. So I don't know right now how many of the errors are due to a lack of precision and how many are due to worse errors. Also, I'm still using data I downloaded a few days ago, so some of it might have been fixed.

Last I checked, there were somewhere between 6000 and 7000 modular forms in the database. So I consider about 25% of the forms questionable, not taking into account the incomplete/inconsistent spaces that Drew has identified.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217937182 What should the dimension be for 15.5.11.a? Unless Stephan just recomputed it (which might of course have happened) it appears as dimension 6 on the webpage which is the same as sage gives.

I did not recompute this and it also looks good for me. What am I missing?

Fredrik — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217939161

[AndrewVSutherland]

@jwbober Is it easy for you to identify spaces where the dimension decomposition is wrong? As I noted above, the test I ran only checked that the sum of the dimensions in the decomposition agreed with the dimension of the space (as listed in the modularforms2 database).

@fredstro 56.10.27 now has an incorrect dimension decomposition. Earlier 56.10.27 was listed as hanving an incomplete or inconsistent set of Hecke orbits Now the number of Hecke orbits in webnewforms agrees with the list of Hecke orbits for the space 56.10.27 in webnewformspace (just one), but the dimension is wrong (2 vs 70).

[jwbober]

I guess I should have been more clear about "obvious". At http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/15/5/11/ it says that the dimension of the space is 6, which is correct. But then it gives a form with coefficients in a degree 8 extension. I now realize that the character is wrong. That is probably supposed to be 15.5.7.a. For 15.5.11.a, the number field should be x^6+73_x^4+1096_x^2+180.

[jwbober]

On Mon, May 9, 2016 at 6:56 PM, Stephan Ehlen notifications@github.com wrote:

How up-to-date is this data now? When did you run it?

Can we take the few ones with trivial character for now as a test case so that I can understand what’s going on? Can you give me some specifics on which coefficients fail for you for 29.4.1.a?

My data is a few days old. The 29.4.1.a was in my list yesterday, so I guess that you fixed it. (Probably trivial characters are all fine now.)

[sehlen]

On May 9, 2016, at 11:09, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 6:56 PM, Stephan Ehlen notifications@github.com wrote:

How up-to-date is this data now? When did you run it?

Can we take the few ones with trivial character for now as a test case so that I can understand what’s going on? Can you give me some specifics on which coefficients fail for you for 29.4.1.a?

My data is a few days old. The 29.4.1.a was in my list yesterday, so I guess that you fixed it. (Probably trivial characters are all fine now.)

Oh, I see. That makes sense then.

How long does this run? Because I would be very interested in you running it again at some point today.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217942786

[jwbober]

The comparison does not take long to run, but it might take a while to get the data. If I could get precise embedding information for everything, I could really run a good comparison.

On Mon, May 9, 2016 at 7:11 PM, Stephan Ehlen notifications@github.com wrote:

On May 9, 2016, at 11:09, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 6:56 PM, Stephan Ehlen notifications@github.com wrote:

How up-to-date is this data now? When did you run it?

Can we take the few ones with trivial character for now as a test case so that I can understand what’s going on? Can you give me some specifics on which coefficients fail for you for 29.4.1.a?

My data is a few days old. The 29.4.1.a was in my list yesterday, so I guess that you fixed it. (Probably trivial characters are all fine now.)

Oh, I see. That makes sense then.

How long does this run? Because I would be very interested in you running it again at some point today.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217942786>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217943175

[AndrewVSutherland]

@fredstro Looks like you have made good progress on the incomplete/inconsistent list, now down to 29 (from about 70). Here is the current list (as of 2 minutes ago):

Hecke orbit data in webnewforms for space 48.8.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 11.19.10 is incomplete or inconsistent Hecke orbit data in webnewforms for space 23.11.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 92.10.91 is incomplete or inconsistent Hecke orbit data in webnewforms for space 25.12.24 is incomplete or inconsistent Hecke orbit data in webnewforms for space 27.7.26 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.67.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.79.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.73.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.4.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 31.3.30 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.9.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 91.7.90 is incomplete or inconsistent Hecke orbit data in webnewforms for space 30.8.19 is incomplete or inconsistent Hecke orbit data in webnewforms for space 31.5.30 is incomplete or inconsistent Hecke orbit data in webnewforms for space 19.3.18 is incomplete or inconsistent Hecke orbit data in webnewforms for space 51.4.43 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.7.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 23.7.22 is incomplete or inconsistent Hecke orbit data in webnewforms for space 55.11.54 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.85.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 3.91.2 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.10.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.5.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.6.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.11.31 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.11.17 is incomplete or inconsistent Hecke orbit data in webnewforms for space 48.12.47 is incomplete or inconsistent Hecke orbit data in webnewforms for space 56.11.13 is incomplete or inconsistent

[sehlen]

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon. Are 53 bits (but really 53 bits and not the 0 correct bits we had (see also https://github.com/LMFDB/lmfdb/issues/1223 https://github.com/LMFDB/lmfdb/issues/1223)) ok for you to compare the data for now?

On May 9, 2016, at 11:13, Jonathan Bober notifications@github.com wrote:

The comparison does not take long to run, but it might take a while to get the data. If I could get precise embedding information for everything, I could really run a good comparison.

On Mon, May 9, 2016 at 7:11 PM, Stephan Ehlen notifications@github.com wrote:

On May 9, 2016, at 11:09, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 6:56 PM, Stephan Ehlen notifications@github.com wrote:

How up-to-date is this data now? When did you run it?

Can we take the few ones with trivial character for now as a test case so that I can understand what’s going on? Can you give me some specifics on which coefficients fail for you for 29.4.1.a?

My data is a few days old. The 29.4.1.a was in my list yesterday, so I guess that you fixed it. (Probably trivial characters are all fine now.)

Oh, I see. That makes sense then.

How long does this run? Because I would be very interested in you running it again at some point today.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217942786>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217943175

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217943862

[jwbober]

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon. Are 53 bits (but really 53 bits and not the 0 correct bits we had (see also https://github.com/LMFDB/lmfdb/issues/1223 < https://github.com/LMFDB/lmfdb/issues/1223>)) ok for you to compare the data for now?

Yes, I think 53 correct bits should be enough. Is the change for newly inserted data, or for all of the data? (Or are the embeddings computed on the fly? That seems like it can be costly.)

I thought I was extracting the embeddings from the database, but maybe the code I am running is computing them on the fly, in which case I should restart it and make sure I have the newest LMFDB code.

[AndrewVSutherland]

@sehlen

I notice that http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/21 has no Hecke orbit spaces available but http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/ still gives a link to it. I thought that in this situation the link to the list of newforms would be grayed out? Or are you in the process of putting the newforms in?

[sehlen]

On May 9, 2016, at 11:41, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon. Are 53 bits (but really 53 bits and not the 0 correct bits we had (see also https://github.com/LMFDB/lmfdb/issues/1223 < https://github.com/LMFDB/lmfdb/issues/1223>)) ok for you to compare the data for now?

Yes, I think 53 correct bits should be enough. Is the change for newly inserted data, or for all of the data? (Or are the embeddings computed on the fly? That seems like it can be costly.)

It is being used for all new data and all data that shows any kind of inconsistency. It is stored in the db.

I thought I was extracting the embeddings from the database, but maybe the code I am running is computing them on the fly, in which case I should restart it and make sure I have the newest LMFDB code.

If you use the Webnewform classes then it uses the data stored in the db. Are you?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217951713

[sehlen]

@AndrewVSutherland

We are. I am only concerned with trivial character (although basically done but I’m ensuring we have good complete “rectangles” of data in the db with no “gaps" ).

On May 9, 2016, at 11:42, AndrewVSutherland notifications@github.com wrote:

@sehlen https://github.com/sehlen I notice that http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/21 http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/21 has no Hecke orbit spaces available but http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/ http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/32/2/ still gives a link to it. I thought that in this situation the link to the list of newforms would be grayed out? Or are you in the process of putting the newforms in?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217951863

[jwbober]

Here is the code that I am currently running to get embeddings: https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4

I started about 30 minutes ago and it is currently at 1901/5624.

Maybe I can modify it to grab the algebraic numbers and compute the embeddings, instead of relying on the embeddings from the database.

[sehlen]

On May 9, 2016, at 11:48, Jonathan Bober notifications@github.com wrote:

Here is the code that I am currently running to get embeddings: https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4 https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4 I started about 30 minutes ago and it is currently at 1901/5624.

Maybe I can modify it to grab the algebraic numbers and compute the embeddings, instead of relying on the embeddings from the database.

No, it’s okay because they should be correct or corrected if not so it is good to use the data because then you’re checking it!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217953786

[jwbober]

On Mon, May 9, 2016 at 7:50 PM, Stephan Ehlen notifications@github.com wrote:

On May 9, 2016, at 11:48, Jonathan Bober notifications@github.com wrote:

Here is the code that I am currently running to get embeddings: https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4 < https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4> I started about 30 minutes ago and it is currently at 1901/5624.

Maybe I can modify it to grab the algebraic numbers and compute the embeddings, instead of relying on the embeddings from the database.

No, it’s okay because they should be correct or corrected if not so it is good to use the data because then you’re checking it!

Yes, but it would be good to distinguish between the two different cases of errors.

[sehlen]

On May 9, 2016, at 11:48, Jonathan Bober notifications@github.com wrote:

Here is the code that I am currently running to get embeddings: https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4 https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4

Good, here you use the db and that’s what you should do.

I started about 30 minutes ago and it is currently at 1901/5624.

Well, we should run it again once we have actually dealt with more of the modular forms with non-trivial character but at least for level <= 100 I hope not to see any trivial character problems anymore (and much more data should be available than with your last test).

Maybe I can modify it to grab the algebraic numbers and compute the embeddings, instead of relying on the embeddings from the database.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217953786

[sehlen]

On May 9, 2016, at 11:51, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:50 PM, Stephan Ehlen notifications@github.com wrote:

On May 9, 2016, at 11:48, Jonathan Bober notifications@github.com wrote:

Here is the code that I am currently running to get embeddings: https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4 < https://gist.github.com/jwbober/d4818253a908cde68cb2d46ec0fd76a4> I started about 30 minutes ago and it is currently at 1901/5624.

Maybe I can modify it to grab the algebraic numbers and compute the embeddings, instead of relying on the embeddings from the database.

No, it’s okay because they should be correct or corrected if not so it is good to use the data because then you’re checking it!

Yes, but it would be good to distinguish between the two different cases of errors.

That’s true but we essentially do this in our recomputing/fixing routine!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217954577

[jwbober]

On Mon, May 9, 2016 at 7:05 PM, AndrewVSutherland notifications@github.com wrote:

@jwbober https://github.com/jwbober Is it easy for you to identify spaces where the dimension decomposition is wrong? As I noted above, the test I ran only checked that the sum of the dimensions in the decomposition agreed with the dimension of the space (as listed in the modularforms2 database).

I can try, but it requires writing some nontrivial code, and I don't know how often I'll be able to actually identify the dimension decomposition with my data. It's not something I've tried systematically. (The only way that I know how to do it is to multiply (x - a_p) together for all the different embeddings of a_p and hope that I have enough precision to get a polynomial with integer coefficients.)

So this is something that is unlikely to happen today.

[jwbober]

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.)

[sehlen]

Here’s the code I use which uses a sort of “hidden” function that John Cremona ones wrote:

you have to import

from sage.rings.number_field.number_field import refine_embedding

and then if K is a number field:

embeddings = K.complex_embeddings() embeddings = map(lambda x: refine_embedding(x,Infinity), embeddings)

and then I apply the embeddings to all coefficients and coerce them into ComplexField(53)

On May 9, 2016, at 12:06, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.) — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217958852

[jwbober]

It looks like I'm not doing any more on this tonight, having been distracted by database problems. I had been trying to compute embeddings to higher precision, and I'm trying to do that again with the data from the copy on the Bristol machine, but it goes very slow. I'm not even sure that it will be done by the morning,

On Mon, May 9, 2016 at 9:15 PM, Stephan Ehlen notifications@github.com wrote:

Here’s the code I use which uses a sort of “hidden” function that John Cremona ones wrote:

you have to import

from sage.rings.number_field.number_field import refine_embedding

and then if K is a number field:

embeddings = K.complex_embeddings() embeddings = map(lambda x: refine_embedding(x,Infinity), embeddings)

and then I apply the embeddings to all coefficients and coerce them into ComplexField(53)

On May 9, 2016, at 12:06, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.) — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217958852>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217976054

[davidfarmer]

I think we have pretty good data now in the rectangles described at the top of the modular forms page.

On Mon, 9 May 2016, Jonathan Bober wrote:

It looks like I'm not doing any more on this tonight, having been distracted by database problems. I had been trying to compute embeddings to higher precision, and I'm trying to do that again with the data from the copy on the Bristol machine, but it goes very slow. I'm not even sure that it will be done by the morning,

On Mon, May 9, 2016 at 9:15 PM, Stephan Ehlen notifications@github.com wrote:

Here’s the code I use which uses a sort of “hidden” function that John Cremona ones wrote:

you have to import

from sage.rings.number_field.number_field import refine_embedding

and then if K is a number field:

embeddings = K.complex_embeddings() embeddings = map(lambda x: refine_embedding(x,Infinity), embeddings)

and then I apply the embeddings to all coefficients and coerce them into ComplexField(53)

On May 9, 2016, at 12:06, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen notifications@github.com wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.) — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217958852>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217976054

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub[AAM6LAZBobEh8Ksja6UXtRJMdEgLmprQks5p_9B4gaJpZM4IZ_Os.gif]

[jwbober]

I hope that is true.

Also, see http://www.lmfdb.org/L/ModularForm/GL2/Q/holomorphic/29/3/2/a/1/

Maybe L-functions for nontrivial characters need to be turned off, unless you can tell when you know the sign and when you don't.

On Tue, May 10, 2016 at 1:29 AM, davidfarmer notifications@github.com wrote:

I think we have pretty good data now in the rectangles described at the top of the modular forms page.

On Mon, 9 May 2016, Jonathan Bober wrote:

It looks like I'm not doing any more on this tonight, having been distracted by database problems. I had been trying to compute embeddings to higher precision, and I'm trying to do that again with the data from the copy on the Bristol machine, but it goes very slow. I'm not even sure that it will be done by the morning,

On Mon, May 9, 2016 at 9:15 PM, Stephan Ehlen notifications@github.com wrote:

Here’s the code I use which uses a sort of “hidden” function that John Cremona ones wrote:

you have to import

from sage.rings.number_field.number_field import refine_embedding

and then if K is a number field:

embeddings = K.complex_embeddings() embeddings = map(lambda x: refine_embedding(x,Infinity), embeddings)

and then I apply the embeddings to all coefficients and coerce them into ComplexField(53)

On May 9, 2016, at 12:06, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen < notifications@github.com> wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.) — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217958852>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217976054

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub[AAM6LAZBobEh8Ksja6UXtRJMdEgLmprQks5p_9B4gaJpZM4IZ_Os.gif]

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218028583

[AndrewVSutherland]

@fredstro @sehlen It looks like there are now just 5 spaces that have dimension sum errors (and no cases where the heckeorbits listed in webnewformspace dont match the recorfds in webnewforms).

Hecke orbit dimensions [2] do not sum to 70 for space 56.10.27 Hecke orbit dimensions [4, 2] do not sum to 106 for space 92.10.91 Hecke orbit dimensions [1, 1] do not sum to 54 for space 91.7.90 Hecke orbit dimensions [2, 2, 2] do not sum to 58 for space 55.11.54 Hecke orbit dimensions [2, 2, 2] do not sum to 78 for space 56.11.13

[sehlen]

Exactly, this list agrees with ours ;-) These are currently stalled in computing the embeddings in sufficiently high precision. It might or might not finish soon….

On May 9, 2016, at 18:09, AndrewVSutherland notifications@github.com wrote:

@fredstro https://github.com/fredstro @sehlen https://github.com/sehlen It looks like there are now just 5 spaces that have dimension sum errors (and no cases where the heckeorbits listed in webnewformspace dont match the recorfds in webnewforms).

Hecke orbit dimensions [2] do not sum to 70 for space 56.10.27 Hecke orbit dimensions [4, 2] do not sum to 106 for space 92.10.91 Hecke orbit dimensions [1, 1] do not sum to 54 for space 91.7.90 Hecke orbit dimensions [2, 2, 2] do not sum to 58 for space 55.11.54 Hecke orbit dimensions [2, 2, 2] do not sum to 78 for space 56.11.13

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218033617

[davidfarmer]

Those were supposed to be hidden in a previous pull request. Should be updated soon.

On Mon, 9 May 2016, Jonathan Bober wrote:

I hope that is true.

Also, see http://www.lmfdb.org/L/ModularForm/GL2/Q/holomorphic/29/3/2/a/1/

Maybe L-functions for nontrivial characters need to be turned off, unless you can tell when you know the sign and when you don't.

On Tue, May 10, 2016 at 1:29 AM, davidfarmer notifications@github.com wrote:

I think we have pretty good data now in the rectangles described at the top of the modular forms page.

On Mon, 9 May 2016, Jonathan Bober wrote:

It looks like I'm not doing any more on this tonight, having been distracted by database problems. I had been trying to compute embeddings to higher precision, and I'm trying to do that again with the data from the copy on the Bristol machine, but it goes very slow. I'm not even sure that it will be done by the morning,

On Mon, May 9, 2016 at 9:15 PM, Stephan Ehlen notifications@github.com wrote:

Here’s the code I use which uses a sort of “hidden” function that John Cremona ones wrote:

you have to import

from sage.rings.number_field.number_field import refine_embedding

and then if K is a number field:

embeddings = K.complex_embeddings() embeddings = map(lambda x: refine_embedding(x,Infinity), embeddings)

and then I apply the embeddings to all coefficients and coerce them into ComplexField(53)

On May 9, 2016, at 12:06, Jonathan Bober notifications@github.com wrote:

On Mon, May 9, 2016 at 7:27 PM, Stephan Ehlen < notifications@github.com> wrote:

I fixed the embeddings to use “infinite” precision and then force it into 53 bits for now but there should be more options soon.

How can you do that? Do you use embeddings into QQbar? (I am trying that on a fairly high degree example right now and Sage seems to be having a lot of trouble just constructing the list of embeddings.) — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217958852>

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-217976054

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub[AAM6LAZBobEh8Ksja6UXtRJMdEgLmprQks5p_9B4gaJpZM4IZ_Os.gif]

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218028583

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub[AAM6LPgEDyROHSc5KXFG4VCX4EPyIQURks5p_9LlgaJpZM4IZ_Os.gif]

[sehlen]

The space @AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

[jwbober]

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

[fredstro]

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

[AndrewVSutherland]

Which mongodb connection? I'm not having any problems connecting to the mongodb on Warwick.

On 2016-05-10 07:03, Fredrik Strömberg wrote:

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126197

[fredstro]

I am doing my main computations on lehner with a standard sssh tunnel (started by Cremona) to lmfdb it worked fine until half abhor or so ago. Now I keep getting server selection timeout

On 10 May 2016, at 12:07, AndrewVSutherland notifications@github.com wrote:

Which mongodb connection? I'm not having any problems connecting to the mongodb on Warwick.

On 2016-05-10 07:03, Fredrik Strömberg wrote:

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126197 — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126896

[fredstro]

I see now, it works fine from home so something must be wrong with that tunnel. Unfortunately since it is there I can’t open a new tunnel, which means I can’t really do any computations there at the moment…

On 10 May 2016, at 12:07, AndrewVSutherland notifications@github.com wrote:

Which mongodb connection? I'm not having any problems connecting to the mongodb on Warwick.

On 2016-05-10 07:03, Fredrik Strömberg wrote:

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126197 — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126896

[AndrewVSutherland]

ps -C ssh then kill the offending pid?

On 2016-05-10 07:11, Fredrik Strömberg wrote:

I see now, it works fine from home so something must be wrong with that tunnel. Unfortunately since it is there I can’t open a new tunnel, which means I can’t really do any computations there at the moment…

On 10 May 2016, at 12:07, AndrewVSutherland notifications@github.com wrote:

Which mongodb connection? I'm not having any problems connecting to the mongodb on Warwick.

On 2016-05-10 07:03, Fredrik Strömberg wrote:

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126197 — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126896

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218127592

[jwbober]

Here is a list of 958 errors for level < 100. (Something like 400 for level < 50), with all the coefficients checked:

errors_1_99_new.txt

[fredstro]

if it was mine I would be able to do it but it is owned by John. In the meanwhile I was able to check Bober’s new error. I don’t think it is an error and the coefficient field is actually correct! It just happens to have been computed by a previous version of sage so the field is just isomorphic to the one you get if you compute it now… For some reason some of the coefficient field that sage gives now are not exactly the same as the ones you got a few years ago…

Fredrik

On 10 May 2016, at 12:15, AndrewVSutherland notifications@github.com wrote:

ps -C ssh then kill the offending pid?

On 2016-05-10 07:11, Fredrik Strömberg wrote:

I see now, it works fine from home so something must be wrong with that tunnel. Unfortunately since it is there I can’t open a new tunnel, which means I can’t really do any computations there at the moment…

On 10 May 2016, at 12:07, AndrewVSutherland notifications@github.com wrote:

Which mongodb connection? I'm not having any problems connecting to the mongodb on Warwick.

On 2016-05-10 07:03, Fredrik Strömberg wrote:

I will have a look at it as soon as the mongodb connection is working again…

Fredrik

On 10 May 2016, at 11:47, Jonathan Bober notifications@github.com wrote:

There are still a lot of problems. I've been computing the embeddings to higher precision, and seem to be able to run more reliable comparisons now. For example, I missed http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/18/7/11/a/ before.

That does not have the right number field (and I don't know what would have the right number field. Doesn't look like character misnumbering). (Should be x^12+42_x^11-165_x^10-71370_x^9-1433985_x^8+42645216_x^7+2438352250_x^6+19378764480_x^5-819344025249_x^4-21266453099898_x^3+155340226123755_x^2+10059647233716762*x+157044341640420289.)

I will post a list in a little while. I have almost 1000 forms with N < 100, and 400 with N < 50.

On Tue, May 10, 2016 at 4:34 AM, Stephan Ehlen notifications@github.com wrote:

The space @AndrewVSutherland https://github.com/AndrewVSutherland have not been recomputed by now but I made sure that the 5 above have no link leading to them at least.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218050902

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218122831

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126197 — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218126896

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218127592 — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1248#issuecomment-218128321