Added two scripts to express Hecke eigenvalues in terms of integral b… #2197
Conversation
|
I like the idea but find the implementation extremely weird! When you do the run to convert all the newforms you will need to be authenticated on the beta database. I would recommend holding off for a while though since right now I and @jvoight and @danyasaki are doing a large-scale rewrite of the Hilbert forms database to sort out some issues there. But you can still write and test your conversion function. |
At some point, I needed an isomorphism between the old field and the new field. In Magma, IsIsomorphic(K_old, K_new) returns a bool, and if the bool is true, also returns the isomorphism. In Sage, K_old.is_isomorphic(K_new) only returns the bool, but not the isomorphism.
I can't authenticate because I don't have an LMFDB account. Or do you mean why I used .xyz instead of .org?
Okay, that's more or less what it does now. I guess I just need to write something that adds the output to a key in the dictionary. But that is part of my question: what should be stored in the attribute 'hecke_eigenvalues'? At the moment the eigenvalues are stored as a list of strings. But would it be better just to store a list of tuples of coefficients and have whatever is rendering the html rewrite this as, e.g., 4 alpha_1 + 10 alpha_2 + ... ? |
|
@jvoight Should one store the eigenvalues as tuples of integers or as strings in alpha_1, alpha_2, ... ? |
|
If K1 and K2 are fields in Sage then K1.embeddings(K2) will give a list of maps from K1 to K2, empty if they are not isomorphic; in your case they have the same degree so any maps returned will be suitable isomorphisms. On the storing of eigenvalues: I think we should store these new coefficient lists in addition to the currently stored eigenvalues, at least in the first instance, as that will make any transition much easier to manage. I can see no reason why not to store them as lists of ints, but there are often reason to store such lists as a single string such as '1,23,-4,5' from which the ints can easily be extracted if needed; this has the advantage that we don't mind if the ints get large in some cases, and I also think it is more efficient in mongo. For the display, we can experiment. I think the display might look too 'busy' if we displayed actual linear combinations such as (\alpha_1+2\alpha_2-3\alpha_3+5\alpha_4), so would try displaying a simple list instead '[1,2,-3,5]'. We would have to define what the alphas are somewhere on the page anyway, and it would be no harder to say something like 'Each eigenvalue is expressed a list of its coefficients with respect to the integral basis *, *, *, * for the Hecke field ***' I have some more thought on using a carefully chosen integral basis instead of the standard one, but I will work out an example first and then post here again. |
|
I tried one manual experiment on an example of what you are doing, on the first form of dimension 10 which is '3.3.49.1-1049.1-b'. The Hecke poly does not look too bad and the optimized one rather similar, but has a discriminant smaller by a factor of d^2 where d=97 * 8830823. Not quite coincidentally this d is a common denominator for the eigenvalues when expressed in the power basis; after clearing the denominator, the max numerator is about 5.1 * 10^11. Switching to the optimized polynomial for the field the common denominator is only 2 * 2069 and max numerator about 3.5 * 10^6 so that has gone down from 12 digits to 7. Next we express with respect to the integral basis (in the optimized representation) and find the maximal coefficient is only 200124. (This example has 169 coefficients). The original 169 strings have total length 44323 while the integral basis coefficients use up 12052 (converting the list of lists to a string just for comparison). Not as good a space saving as I was hoping for, but still a factor of 4. Now comes the best part and my reason for this entire post. The list of 169 eigenvalues expressed in the integral basis is a 169x10 matrix of integers, say M. Using LLL on a 10x10 invertible submatrix I found a unimodular V such that MV is LLL-reduced -- the max entry is now only 22 (compared with 200124)! Hence my suggestion: for each newform do what you propose (express the eigenvalues as Z-linear combinations of an integral basis of the optimised Hecke field) but choose the integral basis so that the resulting coefficients are LLL-reduced. There's an additional cost in that this integral basis depends on the form and not just ts Hecke field, and will have to be displayed on the page; but the benefit is that then the displayed (and stored coefficients) are a lot smaller. If one did this additional step as part of the process in your script, we would need to store the customised integral basis in the database (as a dxd matrix of rationals where d is the dimension) as well as the (smaller) coefficients. I have been suggesting something like this for years, and would love to have some feedback. |
|
Sage has some functionality to do this already, I think, with its
compact_system_of_eigenvalues function. I think this is used somewhere in
the modular forms stuff, but not when the coefficients are actually stored
or displayed.
…On Fri, Jul 21, 2017 at 5:48 AM, John Cremona ***@***.***> wrote:
I tried one manual experiment on an example of what you are doing, on the
first form of dimension 10 which is '3.3.49.1-1049.1-b'. The Hecke poly
does not look too bad and the optimized one rather similar, but has a
discriminant smaller by a factor of d^2 where d=97*8830823. Not quite
coincidentally this d is a common denominator for the eigenvalues when
expressed in the power basis; after clearing the denominator, the max
numerator is about 5.1*10^11. Switching to the optimized polynomial for
the field the common denominator is only 2*2069 and max numerator about
3.6*10^6 so that has gone down from 12 digits to 7. Next we express with
respect to the integral basis (in the optimized representation) and find
the maximal coefficient is only 200124. (This example has 169
coefficients). The original 169 strings have total length 44323 while the
integral basis coefficients use up 12052 (converting the list of lists to a
string just for comparison). Not as good a space saving as I was hoping
for, but still a factor of 4.
Now comes the best part and my reason for this entire post. The list of
169 eigenvalues expressed in the integral basis is a 169x10 matrix of
integers, say M. Using LLL on a 10x10 invertible submatrix I found a
unimodular V such that MV is LLL-reduced -- the max entry is now only 22
(compared with 200124)!
Hence my suggestion: for each newform do what you propose (express the
eigenvalues as Z-linear combinations of an integral basis of the optimised
Hecke field) but choose the integral basis so that the resulting
coefficients are LLL-reduced. There's an additional cost in that this
integral basis depends on the form and not just ts Hecke field, and will
have to be displayed on the page; but the benefit is that then the
displayed (and stored coefficients) are a lot smaller. If one did this
additional step as part of the process in your script, we would need to
store the customised integral basis in the database (as a dxd matrix of
rationals where d is the dimension) as well as the (smaller) coefficients.
I have been suggesting something like this for years, and would love to
have some feedback.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2197 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABXj4-LV1TFjcF5re2dKzxrDkNtqg_6Cks5sQHPQgaJpZM4OekOh>
.
|
|
That's right. See src/sage/modular/modsym/space.py where it is essentially
a one-liner, but does not do the LLL trick.
On 21 July 2017 at 15:55, Jonathan Bober ***@***.***> wrote:
Sage has some functionality to do this already, I think, with its
compact_system_of_eigenvalues function. I think this is used somewhere in
That's right: see src/sage
… the modular forms stuff, but not when the coefficients are actually stored
or displayed.
On Fri, Jul 21, 2017 at 5:48 AM, John Cremona ***@***.***>
wrote:
> I tried one manual experiment on an example of what you are doing, on the
> first form of dimension 10 which is '3.3.49.1-1049.1-b'. The Hecke poly
> does not look too bad and the optimized one rather similar, but has a
> discriminant smaller by a factor of d^2 where d=97*8830823. Not quite
> coincidentally this d is a common denominator for the eigenvalues when
> expressed in the power basis; after clearing the denominator, the max
> numerator is about 5.1*10^11. Switching to the optimized polynomial for
> the field the common denominator is only 2*2069 and max numerator about
> 3.6*10^6 so that has gone down from 12 digits to 7. Next we express with
> respect to the integral basis (in the optimized representation) and find
> the maximal coefficient is only 200124. (This example has 169
> coefficients). The original 169 strings have total length 44323 while the
> integral basis coefficients use up 12052 (converting the list of lists
to a
> string just for comparison). Not as good a space saving as I was hoping
> for, but still a factor of 4.
>
> Now comes the best part and my reason for this entire post. The list of
> 169 eigenvalues expressed in the integral basis is a 169x10 matrix of
> integers, say M. Using LLL on a 10x10 invertible submatrix I found a
> unimodular V such that MV is LLL-reduced -- the max entry is now only 22
> (compared with 200124)!
>
> Hence my suggestion: for each newform do what you propose (express the
> eigenvalues as Z-linear combinations of an integral basis of the
optimised
> Hecke field) but choose the integral basis so that the resulting
> coefficients are LLL-reduced. There's an additional cost in that this
> integral basis depends on the form and not just ts Hecke field, and will
> have to be displayed on the page; but the benefit is that then the
> displayed (and stored coefficients) are a lot smaller. If one did this
> additional step as part of the process in your script, we would need to
> store the customised integral basis in the database (as a dxd matrix of
> rationals where d is the dimension) as well as the (smaller)
coefficients.
>
> I have been suggesting something like this for years, and would love to
> have some feedback.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#2197 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABXj4-LV1
TFjcF5re2dKzxrDkNtqg_6Cks5sQHPQgaJpZM4OekOh>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2197 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC9N6Z1hpdutk9XotkD-eoRY3fquA6B-ks5sQLvKgaJpZM4OekOh>
.
|
|
Just a comment about lists of strings or lists of ints: What is the max size of an int? 64 bits? We've run into an issue like this before and had to revert back to strings because they were (eventually) too big. JV |
|
What is the current status of this PR? It has been sitting idle for 6 weeks now. It only affects files in the scripts directory, so this isn't a major issue, but I'd like to see it either closed it or merged soon. |
|
I see no harm in merging this, though it is only one step in what could be a major reorganisation of how we store (and possibly display) Hecke eigenvalue data. ANy additional work on that can certainly start from this beginning. I'm sure (as I said above) that there is no need for one function to be done in Magma. |
|
If @SamSchiavone is reading this, would you like to comment? |
|
I've worked some more on the code, so I'll update soon, though it might
have to wait until after this weekend. My compromise with the uncertainty
regarding what kind of basis would be best is to include the basis as an
input to the function.
…On Thu, Sep 7, 2017 at 10:24 AM, John Cremona ***@***.***> wrote:
If @SamSchiavone <https://github.com/samschiavone> is reading this, would
you like to comment?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2197 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AZQetw6Ws1nHQ9QYC32oUubrtQDAO4lJks5sf6gggaJpZM4OekOh>
.
|
|
OK thanks Sam. We'll leave the PR open for now, so that if you push more to your branch the PR will automatically get updated. |
|
All right, I've updated to the most recent version of the script. Thanks for explaining how to use Sage to find an isomorphism between the two fields. At the moment the script uses the integral basis listed in the LMFDB (if the Hecke eigenfield has an entry), but I've included int_basis as an argument to one of the functions in case you want to use something fancier, e.g., an LLL-reduced basis. |
Codecov Report
@@ Coverage Diff @@
## master #2197 +/- ##
========================================
Coverage ? 57.5%
========================================
Files ? 227
Lines ? 29520
Branches ? 4555
========================================
Hits ? 16974
Misses ? 11319
Partials ? 1227Continue to review full report at Codecov.
|
|
Can I merge this? |
…asis