Promotions from beta

[John Cremona]

The following things are currently visible on beta.lmfdb.org but not
www.lmfdb.org (they appear in some colour, possibly purple, in the
sidebar):

1. L-functions: first zeros
2. L-functions: operations
3. Higher genus curves: familes
4. Abelian Varieties / F_q
5. Characters: Hecke
6. Motives: Hypergeometric /Q

I was wondering whether any of these were within reach of being
released soon. Would anyone lie to comment?

1. displays a nice page but I found it hard to adjust the min and max
parameters and get anything. Can it be made releasable?
2. was an experiment of a few years ago which can show some nice
examples but is easy to break, and goes against our convention of not
doing non-trivial computations on the fly.
3. looks nice now -- would Jennifer Paulhus like to say if there is
more she wants to do with this before it is released?
4. is very new but apart from writing some missing knowls is there
much to do before it is released?
5. may be in a better state than at first glance -- clicking "select a
number field" is no use, it just takes you to the main number field
browse & search page, but for the fields listed there's a lot of good
stuff to see (with a missing knowl). Is it just a question of making
the front page better?
6. is surely mature enough by now -- apart from some missing knowls?

John

[Andrew Sutherland]

Just a few quick comments (I haven't looked closely at 1,2,5 yet):

* I think 3 and 4 are both in good shape and would consider them candidates for promotion.  I would encourage others to take a closer look and weigh in with there opinions.

* Regarding 6, it looks to me like there is still a fair amount of data missing -- many of the entries listed in the browse table on the front page give 0 results when you click on them (or if these are intended to just be counts with no data behind them, they shouldn't be hyperlinks).  The front page needs right side-bar entries for completeness, source of the data, label format, etc..  And the roots on the circle pictures don't seem to display correctly (at least on my browser), see http://beta.lmfdb.org/Motive/Hypergeometric/Q/A1.1_B3 for example.

[Christelle Vincent]

Hi everyone,

I of course support the promotion of 4 (Abelian varieties over FF_q) since it is my database :) A few words: We have received a lot of good comments on our pull request when it was originally merged to beta, and while we haven’t acted on them, I very much plan to make all of these modifications and to write the necessary knowls.

My timeline right now is to do this when the semester at UVM ends, which is in mid-May. I would think that if there is support from others, the promotion could happen in late May after the updates are made.

Christelle

--
You received this message because you are subscribed to the Google Groups "lmdb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+uns...@googlegroups.com.
To post to this group, send email to lm...@googlegroups.com.
Visit this group at https://groups.google.com/group/lmdb.
For more options, visit https://groups.google.com/d/optout.

[David Roe]

On Fri, Apr 21, 2017 at 10:49 PM, Christelle Vincent <christell...@uvm.edu> wrote:

Hi everyone,

I of course support the promotion of 4 (Abelian varieties over FF_q) since it is my database :) A few words: We have received a lot of good comments on our pull request when it was originally merged to beta, and while we haven’t acted on them, I very much plan to make all of these modifications and to write the necessary knowls.

My timeline right now is to do this when the semester at UVM ends, which is in mid-May. I would think that if there is support from others, the promotion could happen in late May after the updates are made.

I can also help out on some of these in mid May.

David

Christelle

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.
Visit this group at https://groups.google.com/group/lmdb.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

[John Jones]

I am afraid 6 is definitely not ready for prime time.  Some of the data is faulty and needs to be reentered.  There are still design issues related to searching, and there are some aspects which are simply missing.

I was hoping to bring the HGM people together this summer, but that has been put on indefinite hold.  Part of the problem is working a meeting into people's schedules, and part is that they are working on a book on HGM's which is behind schedule, and I think they want to give that priority.

John

[David Roberts]

Yes, 6 has a considerable way to go before it can be made public.

Christelle

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+uns...@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.


Visit this group at https://groups.google.com/group/lmdb.


For more options, visit https://groups.google.com/d/optout.

--


You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+uns...@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.


Visit this group at https://groups.google.com/group/lmdb.


For more options, visit https://groups.google.com/d/optout.

--


You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+uns...@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.


Visit this group at https://groups.google.com/group/lmdb.


For more options, visit https://groups.google.com/d/optout.

--


You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+uns...@googlegroups.com.

[Jennifer Paulhus]

 re: #3. There are two additional pieces of data I would like to add (Jacobian variety decomps from my own work, and another piece of data which can be used to determine if the closure of the set of Jacobians is a so called special subvariety) I am currently using those two pieces of data to train two undergrads on coding for lmfdb, but we should have these ready to go on beta by the end of our semester (mid May). 

As a side note, these undergrads will be working for me some more in the fall so if anyone has data they would like added to lmfdb but not the time to actually code the pages for it, I'd be happy to hear about it.

Jen

[David Farmer]

I was supposed to do some tidying up on 1, but there are some
issues with the database. I can talk with Jonathan
the next time I see him.

[David Roe]

We've made progress on the Abelian varieties over FF_q since April, and I think it's now ready for the main site.  It's currently accessible at http://www.lmfdb.org/Variety/Abelian/Fq/, though not linked to on the sidebar.

I don't know what the procedure is from here.  If anyone has feedback or suggestions, those are certainly welcome.

David

On Fri, Apr 21, 2017 at 10:49 PM, Christelle Vincent <christell...@uvm.edu> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.
Visit this group at https://groups.google.com/group/lmdb.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

[David Farmer]

Abelian varieties over FF_q looks good to me!
(Admittedly, I know very little about the topic,
so I just clicked around for a while and opened some knowls).

> lmdb+uns...@googlegroups.com.

> To post to this group, send email to lm...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lmdb.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "lmdb" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> lmdb+uns...@googlegroups.com.

> To post to this group, send email to lm...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lmdb.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "lmdb" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> lmdb+uns...@googlegroups.com.

[John Cremona]

One small correction to David Roe's advertisement: the latest code is
on beta.lmfdb.org but not yet on www.lmfdb.org so if you go to (e.g.)
http://beta.lmfdb.org/Variety/Abelian/Fq/5/3/a_h_ab_bg_c you will see
some nice new things (newton polygons) which are not yet on the
production website.

John

[David Farmer]

I submitted a small issue (which is about Abelian/Fq but
should not stop the promotion from beta) and added
abvar as an issue tag)

https://github.com/LMFDB/lmfdb/issues/2213

It says:

I suggest shortening the last line in the properties box of Abelian/Fq/
to

Labels for abelian varieties
or
Labels for isogeny classes

because the current line is very long and makes the box unacceptably wide.

[Andrew Sutherland]

I had a chance to play around a little with the latest abelian varieties pages.  In general I think they look very good!  I did notice a few small things:

I had a chance to play around with the new version a bit and did find a few small bugs and a few things that were confusing/troubling:

(1) If you enter an invalid search value (e.g. "cat") for base field or dimension, the error message refers to input fields Q and G, respectively, which I think should be "base field" and "dimension".

(2) It would be nice if points on variety and points on curve let you specify ranges; you can specify lists of values, but if you specify a range you get no matches (and no error message, which is potentially confusing).  (As an aside, I really like the fact that you can specify a negative value for the number of points on the "virtual curve", very cool!)

(2)  If you set dimension to 3 and principally polarizable to yes you get 0 matches, and if you set principally polarizable to no you also get 0 matches, but if you make it unrestricted you get 117148 matches.  I assume this is because you simply don't know which isogeny classes are principally polarizable, but this is potentially confusing, especially since in dimensions 1 and 2 things work as one would expect (so if you do a search with prinicpally polarizable set to yes or no and dimension unspecified you will get a bunch of results, but none will have dimension greater than 2).

(4)  Similar to (3), if you set Jacobian to yes you will get no matches if dimension is 3 or greater.  But if you set Jacobian to no and dimension to 3 you now do get matches (523), which I presume is because these 523 have a negative number of points on the "curve".  But if you now also set principally polarizable to no, you get zero matches, which is potentially confusing (one might conclude that these 523 are all principally polarizable but not Jacobians, but is that really true?).

 

[David Roe]

On Wed, Aug 2, 2017 at 1:41 PM, Andrew Sutherland <andrewvs...@gmail.com> wrote:

I had a chance to play around a little with the latest abelian varieties pages.  In general I think they look very good!  I did notice a few small things:

I had a chance to play around with the new version a bit and did find a few small bugs and a few things that were confusing/troubling:

(1) If you enter an invalid search value (e.g. "cat") for base field or dimension, the error message refers to input fields Q and G, respectively, which I think should be "base field" and "dimension".

Fixed.

 

(2) It would be nice if points on variety and points on curve let you specify ranges; you can specify lists of values, but if you specify a range you get no matches (and no error message, which is potentially confusing).  (As an aside, I really like the fact that you can specify a negative value for the number of points on the "virtual curve", very cool!)

This isn't easy to fix.  The problem is that the point counts are stores as strings, since they can get very large.  This means that the method we have of dealing with ranges (adding "$gte" and "$lte" conditions) won't work.  If you know how to get Mongo to deal with very large integers correctly, that would clearly be the best solution.  In lieu of that, I can add an error message if the search string contains a hyphen....

(2)  If you set dimension to 3 and principally polarizable to yes you get 0 matches, and if you set principally polarizable to no you also get 0 matches, but if you make it unrestricted you get 117148 matches.  I assume this is because you simply don't know which isogeny classes are principally polarizable, but this is potentially confusing, especially since in dimensions 1 and 2 things work as one would expect (so if you do a search with prinicpally polarizable set to yes or no and dimension unspecified you will get a bunch of results, but none will have dimension greater than 2).

(4)  Similar to (3), if you set Jacobian to yes you will get no matches if dimension is 3 or greater.  But if you set Jacobian to no and dimension to 3 you now do get matches (523), which I presume is because these 523 have a negative number of points on the "curve".  But if you now also set principally polarizable to no, you get zero matches, which is potentially confusing (one might conclude that these 523 are all principally polarizable but not Jacobians, but is that really true?).

We don't know much about which classes are Jacobians/principally polarizable in dimension larger than 2 (your hypothesis about negative curve point counts is the main way that we can draw any kind of conclusion).  In the database, each field can store 1 (known yes), -1 (known no) or 0 (unknown).  When you do a search, you can ask to restrict to only those with a 1 in the appropriate field, to those with a -1 in the appropriate field, or place no restriction.  You could add other conditions (matching 0 or 1 for example), but that seems like it would get a bit unwieldy.  Do you have a suggestion for how these kind of searches should work?

David

 

--
You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

[Kiran Kedlaya]

I could certainly imagine wanting to search for "yes or unknown" or for
"no or unknown", so one option would be to add those two as search
options. I don't foresee as much need to match on "yes or no" or "unknown".

Related point: it might make sense to have "principally polarizable" and
"includes a Jacobian" as line items in the properties box.

Kiran

[John Jones]

On Wed, Aug 2, 2017 at 11:21 AM, David Roe <roed...@gmail.com> wrote:

On Wed, Aug 2, 2017 at 1:41 PM, Andrew Sutherland <andrewvs...@gmail.com> wrote:

I had a chance to play around a little with the latest abelian varieties pages.  In general I think they look very good!  I did notice a few small things:

I had a chance to play around with the new version a bit and did find a few small bugs and a few things that were confusing/troubling:

(1) If you enter an invalid search value (e.g. "cat") for base field or dimension, the error message refers to input fields Q and G, respectively, which I think should be "base field" and "dimension".

Fixed.

 

(2) It would be nice if points on variety and points on curve let you specify ranges; you can specify lists of values, but if you specify a range you get no matches (and no error message, which is potentially confusing).  (As an aside, I really like the fact that you can specify a negative value for the number of points on the "virtual curve", very cool!)

This isn't easy to fix.  The problem is that the point counts are stores as strings, since they can get very large.  This means that the method we have of dealing with ranges (adding "$gte" and "$lte" conditions) won't work.  If you know how to get Mongo to deal with very large integers correctly, that would clearly be the best solution.  In lieu of that, I can add an error message if the search string contains a hyphen....

We encountered this with number field discriminants.  Our solution is to store a string where a fixed number of digits is prepended to it giving floor(log_10( number of digits in the number )).  So, 2048 is encoded as '0032048'.  Then then string sorting gives the same thing as value sorting.  (If you looked for the code, note discriminants are a little more complicated since we also have to track the sign.)  There is a second solution to the problem using bson pairs for Artin representation conductors.  There are utilities for that in utils.py.  Note, for bson pairs, you need to re-encode the entry if you ever update a single database entry, even if you didn't modify that part of the entry.  This is a minor problem which would have to be incorporated in any scripts for dealing with the database.

John

 

[Andrew Sutherland]

There is a standard workaround for this limitation that is used
elsewhere, e.g. in the number fields database for discriminant, and also
in genus 2 curves, by encoding potentially large integers as strings in
a way that permits range searches. For both number fields and genus 2
curves there is an attribute "disc_abs_key", whose first three digits
encode the number of decimal digits that follow. I notice that you
currently store a whole list of point counts, but to support the search
I think you would only need to create a key for the counts over the base
field (so you could add A_count_key and C_count_key attributes that
would each just be a single string. And in fact I cant imagine the
curve count over the base field is ever going to be bigger than 2^63, so
you could just store this the number of points on the curve over the
base field as an int.

I know its annoying to write code purely to deal with limitations of
mongo db (switching to postgres would solve this particular issue, but
that is not a change we are likely to make soon). But the amount of
code you would need to add to handle this the same way it is elsewhere
is small (really just a few lines), and this is the kind of query that I
can definitely imagine wanting to do.

If you do make this change, use rewrite.py to efficiently update the
fq_isog collection to add the new attribute(s).

Hmm. One quick and easy solution would be to add an "unknown" option to
the current yes/no/unrestricted choices -- this would at least flag to
the user that yes/no is not exhaustive. But I'm open to other
suggestions. You should also explain the situation in the knowl (and
perhaps also say something about it in the completeness knowl).

>
>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "lmdb" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an

>> email to lmdb+uns...@googlegroups.com.

[David Roe]

I can do that.  It might make sense to do any other updates to the data formatting at the same time, so let me know if you notice any other places in https://github.com/LMFDB/lmfdb-inventory/blob/master/db-abvar.md that should be updated (for example, encoding the Galois group as bson pair of integers so that we can use the same Galois search code as number fields do).

As for exactly what update to perform, do we need to support allowing ranges on the counts in degree larger than 1?  For example, something like [10,96-98]?  If not, then we can encode the first entry in the list as an int, as Drew suggests.

I've added this to https://github.com/LMFDB/lmfdb/pull/2211, which John has been reviewing.  I haven't made any changes to knowls yet though.

David

 

--
You received this message because you are subscribed to the Google Groups
"lmdb" group.
To unsubscribe from this group and stop receiving emails from it, send an

email to lmdb+unsubscribe@googlegroups.com.

To post to this group, send email to lm...@googlegroups.com.
Visit this group at https://groups.google.com/group/lmdb.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lmdb" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lmdb+unsubscribe@googlegroups.com.

[John Jones]

As it stands, global number fields use the bson pair, and local number fields don't.  I think the bson pair is slightly faster for searching, but is a little harder to maintain since it needs to be reencoded whenever the entry is copied (e.g., when using rewrite).

John

[David Roe]

I've been working on abelian varieties for the last few months and would like to again propose them for the production site; you can see the most recent version at beta.lmfdb.org/Variety/Abelian/Fq/, and the pull request for removing the beta status at https://github.com/LMFDB/lmfdb/pull/2305.

Changes include:

* Adding data so that every simple abelian variety now has a corresponding number field in the database (thanks to John Jones)

* Adding the ability to search by Galois group, which are now stored as bson pairs

* Improvements to indices to speed up searching, along with some changes to the data format, recorded in lmfdb-inventory (thanks to Edgar and Drew for their help)

* Marking some varieties as not Jacobians due to not satisfying some conditions on their curve point counts (thanks to Noam)

* Search results are now sorted by a new key which gives the same sort order as lexicographic on g, q, polynomial

David