Display group hashes and identify groups from a description - #7177

…FDB#5556)

Review of PR 44 raised three merge blockers; this addresses all three.

1. New lmfdb/groups/abstract/hash_lookup.py is the single place that turns
   order#hash into a set of groups and decides which stored value may be
   shown as a hash.  gps_groups.hash holds the label counter rather than the
   hash at six of the ten orders with a complete gps_smallhash table (512,
   1152, 1536, 1920, 2187, 15625; checked over every row), so searches at
   those orders resolve through gps_smallhash, where the answer is complete
   and a unique match is a proof of isomorphism.  The find box, the search
   page, group homepages, the subgroup and quotient popups, the identify
   tool and the optional column all go through the resolver, and a counter
   is never displayed under the group.hash knowl.  A computed hash missing
   from a complete table now reports a data problem instead of rendering an
   empty paragraph.

   gps_smallhash has 4.2*10^8 rows and only an (order, hash) index, so the
   real hash of a group at those six orders cannot be fetched for display
   ((order, counter) is a 6-minute sequential scan); the value is suppressed
   rather than replaced by the counter, and the module says why.

2. identify_group parses, builds the group and computes its order inside one
   alarm, turns parser-side GAP or Sage failures into an error page, and
   checks the order cap before factoring the order.  GAP's own start-up is
   deliberately outside the alarm: an alarm that fires during it leaves
   libgap unusable for the whole worker.

3. Matrix entries over GF(p^e) are integer codes 0 <= x < q whose base-p
   digits are coordinates in the power basis of the Conway generator, the
   convention of the FiniteGroups DecodeMat, so every element of GF(q) can
   be entered; Mat(1,4):[[2]] is the generator of GF(4) rather than zero.

Verified with sage -python -m pytest on lmfdb/groups/abstract:
test_abstract_groups.py 22 passed (8 new tests covering the three findings),
test_browse_page.py 71 passed, pyflakes clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…sh searches (LMFDB#5556)

Follow-up review of PR 44 found the hash search still rendered through
gps_groups, so it could not show what the complete tables know.

A new route, /Groups/Abstract/hash/<order>/<value>, answers "which groups
have this order and hash".  At the ten orders with a complete gps_smallhash
table it lists every one of them, including those with no database row
(78125#3521944227884464685 is 78125.82, 78125.335, 78125.340, and only the
last two are in gps_groups), says that the list is complete, links the ones
with a homepage and marks the rest as absent, and redirects when the cluster
determines a single group.  Other orders go on to the ordinary search page,
where the stored column is the hash.  Every "groups with this order and
hash" link now goes through the route: group homepages, subgroup and
quotient popups, the identification tool and the find box, as does a search
whose only constraints are an order and a hash.

The hash column of gps_groups is no longer consulted at the six orders where
it holds the label counter, whatever the order constraint: with no single
order, hash_constraint builds an $or of the column match away from those
orders together with one resolved (order, counter) branch per affected
order, from a single indexed gps_smallhash query.  So a search for the hash
11 no longer returns 512.11, whose stored 11 is its counter, while a search
for 1584677793794603025 finds it with no order given at all.

The optional column still cannot show a hash that only gps_smallhash knows,
which is now documented; where the search itself named one hash at one
order, that value is displayed.  Out-of-range values are refused by the new
route rather than reaching the database, which errors on them.

Verified with sage -python -m pytest on lmfdb/groups/abstract:
test_abstract_groups.py 25 passed (the hash tests now cover the complete
cluster page, the popup and identification links into it, the label with no
homepage, and the false-positive cases), test_browse_page.py 71 passed,
pyflakes clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…#5556)

collapse_ors() combines two $or conditions by updating each old branch with
each new one, which discards the old condition wherever the two name the same
column.  They do here: an order list parses to
{"$or": [{"order": 512}, {"order": 2016}]} and every branch of
hash_constraint() names an order too, so the foiled query asked for the hash at
every order except the six counter-storing ones, and looked up order-512
counters whether or not 512 was one of the orders asked for.  merge_constraint()
intersects the two conditions with $and instead, which is what SearchParser
already does for negated inputs.

searched_hash() read the order out of N#h without consulting the order box, so
the early redirect to the hash page answered a request that names two different
orders, which parse_hashes() rejects.  It now returns nothing unless the two
agree, and a range or a list of orders never agrees, so those go to the ordinary
parser and its error.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

An order and a hash on their own are a lookup, not a search: the request the
test made was redirected to the hash page and on to the homepage of 512.11,
which shows no hash, and the assertion was met by the structural hash that the
subgroup popups carry in their profiledata.  A second condition keeps the
request a table of results, where the column really does supply the hash that
an order-512 row cannot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>