Skip to content

Your First Hunt

This walkthrough explains the complete Rank Hunter lifecycle without assuming you already know the internal terminology.

The goal is not to maximize rank on the first run. The goal is to understand how a candidate becomes a retained curve and how evidence is promoted.

1. Choose the search source

Open Search.

Use Family when you want to search specializations of an installed parameterized elliptic-curve family. A Family plugin may provide its own parameter ranges, candidate generator, charts, presets, or specialized search worker.

Use General when the search does not depend on a Family plugin.

If you want Rank Hunter to choose a prebuilt search workflow, open Auto instead. If you want exact control over the stage sequence, use Pipelines.

2. Generate a Candidate Pool

For Family work, generate a pool under Candidates → Generate or through the Family search page.

A Candidate Pool is a persistent queue, not a proof object. It normally stores:

  • parameter;
  • ranking score;
  • prime/scoring provenance when available;
  • Family/plugin identity and version;
  • exact family/chart metadata when supplied by the plugin;
  • search status and a link to a retained curve if one is eventually created.

Candidate generation should be cheap enough to run over a much larger region than the expensive point search.

See Candidate Pools.

3. Screen before you spend

Search and Pipeline stages are intentionally heterogeneous. Some stages only rank candidates. Others search for rational points. Others produce exact geometry, transform populations, or attempt proof.

A useful order is usually:

large population
→ cheap arithmetic score
→ keep a smaller population
→ exact/family point search
→ retain promising curves
→ expensive certification

Do not interpret a high heuristic score as rank.

For the built-in General short-Weierstrass score, Rank Hunter uses exact point counts at good small primes and stores the scoring provenance. It is still a heuristic.

When a search starts, Rank Hunter creates durable orchestration state and normally queues work through Jobs.

Keep track of:

  • Candidate Pool name/id;
  • Family/plugin and version;
  • target rank or retention threshold;
  • point-search heights/denominator bands;
  • timeouts;
  • number of candidates selected;
  • Pipeline preset/stages when applicable.

These settings are part of the research record. A later run that “looks similar” may not be mathematically or computationally identical.

5. Read job status correctly

Open Jobs while the search runs.

Common outcomes include:

  • completed — the bounded computation finished;
  • timeout — the budget expired; the mathematical question is unresolved;
  • error — the engine or wrapper failed; this is not a negative mathematical result;
  • partial/inconclusive — some work finished but the intended coverage was incomplete.

A completed no-hit point search only says no point was found in the searched region/model. It does not prove there are no rational points outside that region.

6. Open a retained curve

When a candidate produces durable scientific evidence, it can be linked to a row under Curves.

A curve page should be read in layers:

  1. exact model — the stored Weierstrass coefficients;
  2. provenance — Family/plugin, parameter, source candidate, charts/transforms;
  3. point ledger — exact rational points and their statuses;
  4. rank evidence — rigorous lower/upper bounds and exact rank if closed;
  5. history — jobs, searches, evidence records, metadata.

The live rank state is derived from evidence. Do not rely on an old log line when the curve page has newer evidence.

7. Understand point count vs. rank

Suppose a search stores 12 exact rational points. That does not automatically mean rank \(\ge 12\).

Points may:

  • be duplicates under sign/model transport;
  • lie in the subgroup generated by earlier points;
  • be linearly dependent in the Mordell–Weil group;
  • be torsion.

Use Independence to certify new directions.

Once Rank Hunter has enough exact independent points, the rigorous lower bound increases.

8. Deep-search a good curve

Open Target when one retained curve deserves more compute.

Target Search is appropriate when:

  • the curve already has a strong lower bound;
  • a Family search found a particularly good specialization;
  • you want higher point-search heights or a different denominator band;
  • you want family-specific geometry or covering work;
  • you want to continue from the current exact point ledger.

A failed Target run does not erase prior evidence.

See Target Search.

9. Try to close the rank

When the lower bound is worth certifying further, use Descent or the CLI rank-bounds pipeline.

Example:

sage -python -m rank42.cli rank-bounds \
  --db rank42.db \
  --curve-id 123 \
  --engine auto \
  --timeout 300

The important outputs are rigorous upper bounds and whether they meet the current lower bound.

If lower = upper, Rank Hunter can record exact rank.

10. Preserve provenance before publishing

Before sharing a result, record:

  • exact curve model;
  • parameter/family/plugin version;
  • exact point set used for the lower bound;
  • independence/certificate evidence;
  • upper-bound engine and result if claiming exact rank;
  • timeouts/errors separately from completed computations;
  • exports or certificates needed for independent reproduction.

External references such as ICARM are useful comparison data, but an external rank label is not automatically local Rank Hunter proof.

A minimal first-run checklist

You are ready to move beyond the tutorial when you can answer all of these questions for a retained curve:

  • Which Candidate Pool did it come from?
  • What exact curve model is stored?
  • Which points are exact?
  • Which points are certified independent?
  • What is the rigorous lower bound?
  • Is there a rigorous upper bound?
  • Did any stage time out?
  • Which plugin/version generated the curve?
  • Which job or Pipeline Run produced the result?

Next: What Counts as Proof?.