-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add supersingular primes #2323
Comments
Right now the database only contains ap for the first 25 primes (p<100) for elliptic curves over Q, which will not include many supsersingular primes. Of course it would be easy to increase this number. At the moment they are not used for much: only for when we have p-adic regulator data (quite small conductor and positive rank), in order to dcide which primes to display on a page such as http://beta.lmfdb.org/EllipticCurve/Q/37/a/1 (in the drop-down "Choose a prime" list). |
Oh, well, a one-off computation to give supersingular primes < 1000 (or another bound) seems easy to do. Should we store the a_p's the come from this, or not? |
Probably sufficient just to store the primes, since the ap can easily be recomputed, and will anyway be 0 for p>3 (genus 1!). I can imagine people wanting to search on which primes are supersingular. What about CM curves? I also saw that for elliptic curves over number fields, currently we store no ap at all. Another job for someone. |
I would suggest just storing and displaying the first n supersingular/superspecial primes up to some fixed bound N, say n=5 or 10 and N=10^9. Then we can treat all curves the same way. I agree that it is not necessary to store the ap's (or more generally the L-polynomials). |
I agree with Drew's idea. For CM, we should also add the note to say that
the set of supersingular primes is the set of ramified or inert primes in
Q(\sqrt{-d}).
…On 13 November 2017 at 05:12, Andrew Sutherland ***@***.***> wrote:
I would suggest just storing and displaying the first n
supersingular/superspecial primes up to some fixed bound N, say n=5 or 10
and N=10^9. Then we can treat all curves the same way. I agree that it is
not necessary to store the ap's (or more generally the L-polynomials).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2323 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AATtBsDCOuF1e-1YrDrlglFGzAzspVxLks5s2BYCgaJpZM4Qa7CU>
.
|
Would it not be better to sore the supersingular primes up to a fixed bound rather than limit the number (as well or instead)? Say we store the first 5, someone searches for curves with 83 supersingular but with 5 smaller ss primes, then the curve would not be found. |
Looking back at this. I would be more flexible and would store at least n supersingular primes, and all the supersingular primes up to somebound (if the curve is not CM). |
This came up again in the context of hypergeometric motives. I would expect to see all primes up to some bound, for the reason that John gave. For N = 10^5, what is the maximal number of ss primes less than N for a single non-CM curve in the database? |
Asymptotically, Lang--Trotter predicts
There is also an expression for |
Seems like this would be easy to add in genus 1 and useful to see, up to a reasonable bound. The bound may be just the number of a_pp's that are stored in the L-function?
In genus 2, maybe we just list the superspecial (or supersingular) primes; I suppose the case p-rank 1 is also interesting?
The text was updated successfully, but these errors were encountered: