One calling convention: smaller divisor first, coefficients descending, in all twelve families

[salindne]

Deg<i><j>ADD names the degrees of its two input divisors, and the repository disagreed with itself about what that meant. Three families read the digits as positional — smaller-degree divisor first — while genus-3 split read them as merely sorted and took the larger first. Separately, genus-2 split wrote each operand's coefficients ascending where everyone else wrote them descending.

After this PR all twelve families share one convention. Every Deg12ADD in the repository reads (u0, v0, up1, up0, vp1, vp0, …), differing only in the curve-constant tail.

Why the operand half is a correctness problem

A caller who reads the name and passes operands in the genus-2 order gets a silently wrong answer, not an error, because the arities match. That is the defect class that got the inherited *_use_for_odd_even.m files dropped at import for carrying a reversed operand convention.

The coefficient half is genuinely cosmetic, but genus-2 split contradicted itself: Deg2DBL(u1,u0,v1,v0,ccs) and Deg2ADD(u0,u1,v0,v1,…) sat in the same file, so a reader moving between a doubling and an addition met two conventions without leaving the page.

Scope

commit	change
Deg22ADD → Deg2ADD	55 occurrences: 6 formula files, 3 whitebox generators, blockcheck.py
genus-3 split reorder	27 functions, 54 call sites, 3 files
genus-2 split coefficient order	30 signatures, 54 call sites, 6 files, both bases

Three kinds of edit, deliberately not conflated

This is the part worth carrying forward, because the three have different risk and different verification:

1. A pure rename — no operand order to confuse, verifiable by copy-and-diff. Landed first and alone, so the risky diff stayed small.
2. A prefix swap inside a function body, u ↔ up and v ↔ vp with subscripts untouched, the prefix being the divisor identity and the subscript the coefficient index within it.
3. An argument reorder at the call site, with no renaming, because the caller's variables keep their meaning.

Conflating 2 and 3 corrupts the dispatcher. Doing 2 without 3 is a wrong answer with no compile error.

The swap is one pass with a lookup, not three through a sentinel

TOK  = re.compile(r'(?<![A-Za-z0-9_])(up|vp|u|v)([0-9])(?![A-Za-z0-9_])')
SWAP = {"u": "up", "up": "u", "v": "vp", "vp": "v"}
new  = TOK.sub(lambda m: SWAP[m.group(1)] + m.group(2), body)

A sentinel is correct, but its correctness rests on the sentinel never colliding and on nobody reordering the passes later. re.sub with a callback replaces each match independently and never rescans its own output, so u0 → up0 and up0 → u0 in the same pass cannot interfere — the hazard becomes structurally impossible rather than avoided by discipline.

Two things would each have produced a half-applied swap, which is the wrong-answer case, and both were settled by measurement before the first edit rather than discovered after:

• up|vp must precede u|v in the alternation. Python matches leftmost-first, not longest, so the other order matches the u of up0, fails the digit test and skips the token — leaving every up untouched while every u swaps.
• The substitution must be scoped to the target bodies, not the file. up3 is not a divisor coefficient; it is a live scratch temporary in Deg3ADD holding up2². A file-wide pass would have renamed it to u3.

The pattern was run against all three files beforehand and shown to rewrite exactly thirteen token forms while leaving the other fifty-two identifiers beginning u or v alone — upp0–upp3, unp0, vpp0–vpp2, vh0–vh2, vt0–vt2 and the bare u, up, v, vp among them.

The acceptance test for a reorder is that nothing moves

opcount identical per branch, per family, before and after. A reorder that changes a count has changed behaviour. Measured identical across all 42 shapes in each genus-3 split family and every shape in all six genus-2 split families. That gate did not exist when this work was first scheduled; PR41 supplied it.

Two mechanical self-checks ran before any gate: within the swapped bodies the token counts exchange exactly (u 543 ↔ 597, v 602 ↔ 495 in arb), and git diff --stat shows equal insertions and deletions — 1,106/1,106 for arb, 2,200/2,200 for the two specialisations. A partial swap fails both.

The trap that cost two earlier PRs was absent, and was checked rather than assumed

PR21 drifted 56 frozen cases and PR36 another 20, both because a rename touched debug label strings the corpus stores verbatim. Here Deg22ADD never appears inside a label string: genus-3 split labels are numeric and the genus-3 ramified labels were numbered in PR6, carrying the prose name only in a trailing comment. harvested_cases.json holds 0 cases and coverage_baseline.json no Deg-bearing labels. So no frozen-corpus substitution and no re-harvest.

Two other scope facts came from measuring rather than assuming: the whitebox generators and random testers needed no change at all, calling only the ADD dispatcher and never the leaf functions; and doubling was untouched throughout, already descending.

Gates

opcount identical everywhere · whitebox 7,043/7,043 with every branch label unchanged · driver --strict 55,236/55,236 · dominance clean on 39 files · selftest 19/0/0 · blockcheck · three full Magma passes, 30 testers, 0 failures, 0 skips · readme-paths 94/94 · check_paths --strict 259/259.

Two limits, recorded rather than glossed

The _OLD differential was not run. The plan named a same-session old-versus-new comparison as the per-file acceptance test, the technique PR36 used. It was attempted in Python and abandoned after ten minutes without completing — interpreting nine functions of a 10,000-line file at that volume is too slow, and the Magma form is its own piece of tooling. What stands in for it: the frozen corpus was extracted from runs of the old code and records both returned divisors and branch labels, and the new code reproduces every case exactly; driver --strict agrees with an independent Cantor implementation over 55,236 operations across every degree combination; and the specific failure this edit risks, a missed call site feeding old-order arguments to a reordered function, is exactly what the corpus catches, because its cases drive the dispatcher rather than the leaf functions.

One Magma pass took 24m55s of wall clock against the usual five. Not a regression: the suite's own reported times sum to 283s against a 297s baseline, so the formulas did the same work at the same speed. The cause was host contention, traced to an orphaned scratch process from an earlier session.