{"action":"created","issue":{"url":"https://api.github.com/repos/LMFDB/lmfdb/issues/1386","repository_url":"https://api.github.com/repos/LMFDB/lmfdb","labels_url":"https://api.github.com/repos/LMFDB/lmfdb/issues/1386/labels{/name}","comments_url":"https://api.github.com/repos/LMFDB/lmfdb/issues/1386/comments","events_url":"https://api.github.com/repos/LMFDB/lmfdb/issues/1386/events","html_url":"https://github.com/LMFDB/lmfdb/issues/1386","id":155279828,"number":1386,"title":"Identifying coefficient fields on classical modular form pages","user":{"login":"AndrewVSutherland","id":11425002,"avatar_url":"https://avatars.githubusercontent.com/u/11425002?v=3","gravatar_id":"","url":"https://api.github.com/users/AndrewVSutherland","html_url":"https://github.com/AndrewVSutherland","followers_url":"https://api.github.com/users/AndrewVSutherland/followers","following_url":"https://api.github.com/users/AndrewVSutherland/following{/other_user}","gists_url":"https://api.github.com/users/AndrewVSutherland/gists{/gist_id}","starred_url":"https://api.github.com/users/AndrewVSutherland/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AndrewVSutherland/subscriptions","organizations_url":"https://api.github.com/users/AndrewVSutherland/orgs","repos_url":"https://api.github.com/users/AndrewVSutherland/repos","events_url":"https://api.github.com/users/AndrewVSutherland/events{/privacy}","received_events_url":"https://api.github.com/users/AndrewVSutherland/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/LMFDB/lmfdb/labels/classicalMF","name":"classicalMF","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-05-17T14:50:34Z","updated_at":"2016-05-18T13:45:39Z","closed_at":null,"body":"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\r\n\r\nhttp://beta.lmfdb.org/ModularForm/GL2/Q/holomorphic/23/8/1/?group=0\r\n\r\nhas to Hecke orbits in it, one with coefficient field of degree 5 and the other of degree 8, with defining polynomials:\r\n\r\nx^5 + 16x^4 - 320x^3 - 3136x^2 + 25680x + 10816\r\nx^8 - 832x^6 - 1059x^5 + 203052x^4 + 678328x^3 - 13424272x^2 - 73308944x - 37372224\r\n\r\nThe 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\r\n\r\nx^5 - 2x^4 - 104x^3 + 200x^2 + 2037x - 3704\r\n\r\nAside 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).\r\n\r\nThe 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).\r\n\r\nThis 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.\r\n"},"comment":{"url":"https://api.github.com/repos/LMFDB/lmfdb/issues/comments/220030300","html_url":"https://github.com/LMFDB/lmfdb/issues/1386#issuecomment-220030300","issue_url":"https://api.github.com/repos/LMFDB/lmfdb/issues/1386","id":220030300,"user":{"login":"sehlen","id":2471633,"avatar_url":"https://avatars.githubusercontent.com/u/2471633?v=3","gravatar_id":"","url":"https://api.github.com/users/sehlen","html_url":"https://github.com/sehlen","followers_url":"https://api.github.com/users/sehlen/followers","following_url":"https://api.github.com/users/sehlen/following{/other_user}","gists_url":"https://api.github.com/users/sehlen/gists{/gist_id}","starred_url":"https://api.github.com/users/sehlen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sehlen/subscriptions","organizations_url":"https://api.github.com/users/sehlen/orgs","repos_url":"https://api.github.com/users/sehlen/repos","events_url":"https://api.github.com/users/sehlen/events{/privacy}","received_events_url":"https://api.github.com/users/sehlen/received_events","type":"User","site_admin":false},"created_at":"2016-05-18T13:45:39Z","updated_at":"2016-05-18T13:45:39Z","body":"Let me add that I have seen both cases when testing our routine. \r\nMost of the time the coefficients seem to get better, at other times worse.\r\n\r\nBut I have an idea that might work in almost all of the cases, I just have to see why or get enough counterexamples:\r\nWe'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."}}