[P2 replication] Second implementation of the quartic census — where Results A–D actually live

[LightChainr]

Write this without reading our implementation. That is the entire value of the ticket; anything else is a code review, which we can already do.

Why this is the most valuable open item on P2

The manuscript's strongest results — A, B, C, D — all come from the degree ≤ 4, height ≤ 100 census: 158,062,321,920 primitive integer polynomials per interval, decided exactly against four published threshold intervals. That census has one implementation of its C++ fixed-point meet-in-the-middle screen and one of the Sturm decisions on the 16 retained candidates.

The degree ≤ 6 census (§6.5) already has a second implementation and they agree cell by cell (Table 9). That was the cheaper of the two replications. This is the one that matters.

The task

Write an independent census of C(≤4, ≤100) against the four frozen intervals in analysis/pslq_search_contract.json, from the protocol only. For each degree 1–4 and each interval, report:

• the size of the enumerated class;
• how many candidates your screen retains;
• how many polynomials have a real root in the interval;
• the number of distinct such roots;
• the closest member of the class, coefficient by coefficient, and its residual.

Read these, and nothing else from the repo

• analysis/pslq_search_contract.json — the four intervals, verbatim.
• docs/manuscripts/p2-algebraic-exclusion/manuscript.md §3 (the completeness theorem: the class, the screening bound, the exact decisions) and §5 (method).

Do not read scripts/degree4_interval_exclusion.py, scripts/degree4_fixed_point_screen.cpp, or scripts/exact_polynomial_root_certificate.py. If you have read them, say so in the PR; a replication that read the original is worth reporting as such rather than passing off.

Make it differ where a shared bug would hide

The existing degree-6 replication is the model: it enumerates the class in its own code and screens at the interval midpoint where the primary screens at both endpoints. Both are certified consequences of |P'| ≤ D on [0,1], but they evaluate different points against different bounds.

Do the same here. Pick your own enumeration, your own screening point, and ideally your own root-decision path — the degree-6 pair still shares exact_polynomial_root_certificate.py unchanged, which is the acknowledged limit of that replication and is stated in §7.

The check that carries the weight

Equal counts are weak evidence: two implementations can agree by both being empty. What matters is the residual. If we evaluate the closest member at a different point than you do, our residuals must differ, and the mean value theorem caps the difference at D(u−l)/2 for that polynomial's own D = Σ k|a_k|. Agreement inside that allowance, with a non-zero gap that tracks the interval width, is evidence that we are computing the same quantity rather than reporting the same zero.

scripts/degree6_implementation_agreement.py does this comparison for the degree-6 pair; the analogue for degree 4 is part of this ticket.

Two things to expect

1. The census is not an exclusion everywhere. Degrees 1–3 are excluded on all four intervals. At degree 4, the two narrowest intervals are excluded and the two widest retain 1 and 15 surviving quartics. If your run excludes everywhere, something is wrong with it. If it finds a different number of survivors, that is a finding and we want it.
2. Cost. The primary census is a C++ fixed-point screen for a reason; 1.6·10¹¹ polynomials per interval is not a pure-Python job. Budget accordingly, or replicate one interval — the narrowest, which carries Result A — and say so.

Done looks like

• The implementation, committed as received, with its artifacts.
• A cell-by-cell agreement artifact including the residual/mean-value check.
• The manuscript's §7 "Recommended, not done" list loses its first entry, and Table 9's scope line stops saying the quartic census is single-implementation.
• Any disagreement reported as a disagreement. A replication that finds a discrepancy is worth more than one that does not.

[LightChainr]

CLAIMED — 2026-09-13

Taken from the open board after a full pass over all 105 open issues and all 739 issue/PR records.
This ticket had no open and no merged PR pointing at it.

TARGET:   independent second implementation of the degree <= 4, height <= 100 census
BASE:     main
WHERE:    Huawei (ARM 16 vCPU / 32 GiB); optional 4-container partition by interval
MODEL:    deepseek-v4.1-flash

First step

Read ONLY analysis/pslq_search_contract.json and manuscript sections 3 and 5, then write an independent enumerator and an independent screening point. The three primary files named in the ticket are NOT read.

Deliverable

notes + scripts + results for all four frozen intervals, plus a cell-by-cell comparison against the primary implementation with the residual/mean-value check.

Claim boundary

Reading the primary implementation destroys the value of this ticket, so if that happens it will be declared in the PR rather than passed off. A replication that consumed the same screen is not independent replication.

Nothing is closed by this comment. No docs/STATUS.md edit, no merge, no branch rename.
Full repository CI will not be claimed unless actually run.

[LightChainr]

Delivered — PR #749

An independent re-derivation of the degree ≤ 4, height ≤ 100 census, committed as received with
its artifacts. 13 new files, nothing existing touched.

The disclosure has to come first

The three files the ticket names as off-limits — degree4_interval_exclusion.py,
degree4_fixed_point_screen.cpp, exact_polynomial_root_certificate.py — were never read.

But this is not a blind replication, and the ticket is explicit that a replication which read
the original "is worth reporting as such rather than passing off". I read the committed summary
artifacts results/pslq-degree4-*/latest.json before writing the replication, because they define
the comparison quantities. That is recorded in the note, in the result metadata, and in the PR.

Every cell agrees

interval	retention (prim.)	near	root-bearing	distinct roots	closest	residual
jacobsen-2015-eigenvalue	0 / 0	1543 / 1543	0 / 0	0 / 0	agree	agree
mertens-2022-p-med	3 / 3	1548 / 1548	1 / 1	1 / 1	agree	agree
mertens-2022-p-cell	127 / 127	1660 / 1660	15 / 15	15 / 15	agree	agree
yang-zhou-2024-corrected	0 / 0	1543 / 1543	0 / 0	0 / 0	agree	agree

ρ agrees fraction for fraction; the screen bound agrees exactly (20077, 3000086, 80000077,
100065); |C(4,100)| = 157309446881 agrees. The closest member is [-84,99,-7,99,58] on three
intervals and [-97,87,54,98,49] on p-cell, coefficient by coefficient.

Four search paths, and the one that matters

The ticket says to "pick your own enumeration". Three additional paths beyond the local one ran on
the Huawei fleet — 10 containers, 144 vCPU, 560 shards:

• loop — the naive degree-4 nested enumeration with the leading coefficient looped rather
  than solved: 100× the inner work of the local path;
• mitm — the split {0,1,2} | {3,4}, sorted right half, binary search;
• alt — the same enumeration but on a different screen lattice, S = 2^50 instead of
  10^15.

All four returned identical retained sets, alt included. A wrong screen usually produces a
retained set that moves when the lattice moves; this one does not.

The root decision path is also different: monotonicity from the second-derivative bound plus
endpoint signs, not a Sturm chain.

The residual check

The primary evaluates the closest member at the endpoints; the midpoint is a different point. The
mean value theorem caps the difference at D_P (u−l)/2.

jacobsen    residual 1.220964e-9   |P(m)| 1.225831e-9   gap 4.867e-12   cap 1.284e-11   holds
yang-zhou   residual 5.930735e-10  |P(m)| 6.174104e-10  gap 2.434e-11   cap 6.420e-11   holds

The residuals are 95× and 9.2× the cap respectively, so the agreement is on a non-trivial
quantity rather than on two zeros. On mertens-2022-p-med and mertens-2022-p-cell the residual is
exactly 0, and the independent path independently finds the sign change across the interval that
makes it 0.

Two of the ticket's expectations are confirmed: degrees 1–3 are excluded on all four intervals,
and at degree 4 the two widest intervals are not excluded — they carry 1 and 15 root-bearing
quartics.

The 15 distinct roots, without appeal to the primary

The 15 root-bearing quartics of mertens-2022-p-cell were compared pairwise by exact rational
polynomial gcd. No pair shares a non-constant factor, so the 15 roots really are distinct. That
is the part of distinct_roots_in_interval that could otherwise be an artifact of a shared root
counted twice.

What I did not do, and why

The ticket's completion criteria include removing §7's first "Recommended, not done" entry and
changing Table 9's scope line. I did not apply those edits. The honest wording is not "the
quartic census now has a blind second implementation" — it is "an independent re-derivation exists,
written with the committed summaries in hand". Exact suggested text for both edits is in the PR
body; applying it is a two-line change if you prefer.

Not established

No new Monte Carlo, no new p_c, no merge, no docs/STATUS.md edit, no edit to any existing file.
Full repository CI has not been run.