The engine behind the repair study: one composable destroy-and-repair loop where a variant is a declared change over a parent, the shared IO and scorer it sits on with the DFS study, an incrementally-maintained mismatch map, and the definitions of every statistic the study raises.
This page is the apparatus behind the repair study:
how the engine is built, why a new variant is cheap to add, and what every number
on the results means. It is the deliberate twin of the
DFS study's method page,
and it sits on the same shared library: the board, the piece set, the one
canonical scorer and the IO contract all come from a common e2-core / e2-io
crate that the backtracking study uses too. A repaired board and a backtracked
board are therefore scored by the identical code, which is what lets numbers from
the two studies sit on one axis.
Every algorithm in the study is the same destroy-and-repair loop, parameterised by five independent choices:
A variant is a small record naming those five choices, together with the parent it derives from and a one-line description of the single change it adds. Adding a variant means adding one record to the registry, with no new loop code unless the idea is a genuinely new strategy. The "what stacks on what" matrix on the results page is generated from those descriptions, so it cannot drift from the code that ran.
A backtracker builds a board up from nothing; a repair loop always holds a complete board and edits it. The cells worth attacking are the ones touching a broken edge, so the engine keeps a live count, per cell, of the broken interior edges incident to it. Placing or lifting a piece updates only the edges around that one cell, never the whole board, so a conflict-driven destroy operator can ask "which cells touch a mismatch?" without rescanning. The running score is kept the same way: each placement adjusts it by the handful of seams that changed. A full rescan happens exactly once, when the starting board is built; from then on the loop is incremental. This is what makes hundreds of thousands of iterations in sixty seconds possible, and it is the same discipline the ALNS theory page describes as keeping destroy at cost proportional to the hole, not the board.
No engine's self-reported score is trusted. The loop's incremental score is a performance device; the published number is always a fresh canonical re-score of the output board, through the same scorer the site and the DFS study use (matched, non-border, interior adjacencies, counted right and down per cell). A test asserts the incremental score and the canonical score agree after thousands of random place-and-lift edits, so the fast path can be trusted to track the truth rather than drift from it.
For every run the engine records, and the results carry all the way to the page:
The page also draws a convergence curve for a few representative variants: the best score so far, sampled every two hundred iterations, as a typical run progresses. It is the clearest picture of the stall: the curve rises steeply, then goes flat while the iteration count keeps climbing.
Like the DFS study's MRV engine, the repair loop here is written for clarity first. The greedy refill rescans the remaining piece pool for every cell it fills, rather than maintaining candidate lists incrementally, so its iterations-per-second is this clean engine's rather than the best a tuned repair kernel could reach. The ranking by score does not depend on it, since throughput is a separate axis never mixed into the score comparison, but the iteration rates should be read as this engine's, not as the ceiling for destroy-and-repair.
This is a study of the plain repair loop, one decision at a time, at a small fixed budget. It is not the record pipeline: the boards that reach the mid-450s and beyond combine a strong constructive producer, longer runs, and repair as a final polish, and several of the operator findings here would read differently on a near-record board than they do on the mediocre greedy start the loop begins from. Where a result depends on the starting board's quality, the findings page says so. The community's own tuning found, for instance, that conflict-driven and component operators are valuable precisely on near-optimal boards where the few remaining mismatches are the only thing left to fix, the regime this study's short runs never reach.
The engine, the ten variants, the committed per-run results and the grid scripts
all live under the study's
backing directory.
just experiments repair-study rebuilds the engine and reruns the whole grid;
the run is deterministic at a fixed seed, and the corner arrangement is the only
diversity axis.