On the LMFDB search pages, each search text box has a light grey example value given inside the text box - this is the example attribute of the TextBox object. E.g. for the degree of a number field this is "3", for conductor of an elliptic curve this is "389", etc. (Note that this can differ from the example_span value given next to the text box on the right; see issue #6377 for a discussion of that).
I would like to propose that this light grey example value given inside each search text box should always satisfy the following two properties:
- The example value should be a syntactically valid example, i.e. something a user can literally type into that box and get a valid search result from.
- There should exist at least one object in the database with the given example value, i.e. the returned search result should be non-empty.
While both of these properties are already true for most of the example inputs given in the search boxes, there are currently several search boxes which don't have these properties. The most common culprit I've found is that there are a few boxes where the example input contains "or", which is usually not valid input. This can usually be fixed by putting a single valid value in example and moving the alternatives into the example_span text (shown next to the search box).
Here are some examples I've found:
- For ECQ, ECNF, and Genus 2 curves, the "Galois image" box has the example text "13S4 or 13.91.3.2", "7Cs.2.1 or 17B", and "2.45.1 or 3.720.4" resp. This should either be given as a single label, or a comma-separated list in order to be valid input.
- For abelian varieties, the "Non-cyclic primes" box (in advanced search options) has the example text "2 or 2,3,5". This should rather just be "2,3,5".
- The same problem is also given in "Qbar-invariants" box for genus 2 curves, the "Type" and "Kernel order" boxes in the character group search, and the "Group" search box in the conjugacy classes search.
- For ECNF, the "Base change of" box has example text "11a.1", which should instead be "11.a1".
- For abstract groups, the "Automorphism group order" box has the example text "3". But there's no group in the database with automorphism order 3 (it's actually an easy exercise to show this can never happen!)
- For abelian varieties over Fq, both the "Dimension 3 factors" and "Dimension 4 factors" boxes have example text "2", but neither return non-empty searches.
- For rational L-functions, the "Lowest zero" box has example "9.22237" which similarly outputs no results. Same issue with "Central character" box with example "37.1", which also outputs no results.
In principle, both of the above two properties could perhaps be implemented in the CI testing, e.g. for each text box, we simulate a search where we give the example value in the text box and check that it returns a valid non-empty search result.
See also the related issue #6377 for a discussion on the conventions for the example_span values, i.e. what's given next to the search box.
On the LMFDB search pages, each search text box has a light grey example value given inside the text box - this is the
exampleattribute of theTextBoxobject. E.g. for the degree of a number field this is "3", for conductor of an elliptic curve this is "389", etc. (Note that this can differ from theexample_spanvalue given next to the text box on the right; see issue #6377 for a discussion of that).I would like to propose that this light grey example value given inside each search text box should always satisfy the following two properties:
While both of these properties are already true for most of the example inputs given in the search boxes, there are currently several search boxes which don't have these properties. The most common culprit I've found is that there are a few boxes where the example input contains "or", which is usually not valid input. This can usually be fixed by putting a single valid value in
exampleand moving the alternatives into theexample_spantext (shown next to the search box).Here are some examples I've found:
In principle, both of the above two properties could perhaps be implemented in the CI testing, e.g. for each text box, we simulate a search where we give the example value in the text box and check that it returns a valid non-empty search result.
See also the related issue #6377 for a discussion on the conventions for the
example_spanvalues, i.e. what's given next to the search box.