Repository navigation
Research: exact frame search certifies #741 and #626 providers frame-optimal (rediscovers #741; negative result) - #815
Open
Rohansguliani wants to merge 2 commits into
Open
Rohansguliani wants to merge 2 commits into
Rohansguliani wants to merge 2 commits into
Conversation
…optimal Exact LP (HiGHS) and CP-SAT over every frame assignment of the fixed gate sequence of the jp8 and ck provider words; both optimal at the input, for the linearised and the exact-root criterion. Commuting-reorder annealing with exact re-solve gives no gain. Includes the kappa > 0.01 Jensen requirement. Rohan Guliani (@Rohansguliani), with substantial AI assistance.
…olver rediscovers its recipe check_sw4.py reproduces CrocSwap#741's pinned output hash from PR699's SW4 word and shows the frame LP optimum equals CrocSwap#741's weight (linear and exact-root at CrocSwap#741's complex root). CP-SAT with the audit's cone caps finds exactly CrocSwap#741's profile from the PR699 input. Six reorder restarts on CrocSwap#741 give no gain.
Rohansguliani
force-pushed
the
rg/machine-search
branch
from
October 13, 2026 06:40
52175dd to
d8c8b40
Compare
Contributor
|
100-PR batch review at This remains open after scoped triage. Next review step: The claimed exact frame optimum relies on floating LP tolerances and solver status without an exact dual/proof certificate. Review/qualify the universal exclusion before incorporation. This is a specific continuation point, not a rejection or a request to redo already recorded checks. Completed local evidence is retained separately from outstanding whole-head obligations. Batch review, attribution and evidence. Thank you for the contribution. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update: current selected word (#741). Rebased on main after #741 merged. I gave CP-SAT PR699's SW4 word (
d232183f…), using the admissible model with the audit's hpe cone caps and fixed tail frames. In 27 s it returnedOPTIMALwith exactly #741's profile{1:2556,2:334,3:430,4:194,5:56,8:8}, so the solver rediscovers #741's gain without guidance.check_sw4.pyapplies #741's recipe and reproduces its pinned output hashe7804702…. The LP optimum over all frame assignments then equals #741's weight: 18155.950422 linear and 18219.665540 exact-root at #741's complex root, with gaps under 1e-9. So no frame-only change of the selected word can raise κ; PR699's frame slack (6.90 units) is exactly what #741 recovered. Six commuting-reorder restarts on #741, each re-solved by the LP, gave no gain. The receipt isRESULT-SW4.json. This work does not touch the R420/R439 bit or E8 lines (#789/#790/#792, #765/#767/#770).Negative result, scoped. No κ change. By Rohan Guliani (@Rohansguliani), with substantial AI assistance (an AI coding agent wrote the search code and ran the experiments).
The complex side binds the selected κ. In the 64 jp8 calls, unit climbs make up 160,768 of the 181,659 rank-1 children. Paid children are exactly the frame climbs that
hpe_audit_and_transport.py::climbcounts, and the scalar program never reads frames. So I treated every A/B/tail gate frame of the selected provider words as a variable and searched all of them exactly.Result. For #626's
jp8andckwords (content hashes pinned incomplex-k492-owner-repair/data/SPEC.json, rebuilt fresh by the package'sverify.py), the paid profile is optimal over every frame assignment of the fixed gate sequence:The weight is the linearised moment, Σ d·ln(48/d). Each word's rank mass is fixed by its widths, so at the selected root a* the exact criterion is Σ d·(73/d)^a*. That weight is also LP-optimal at the input (gap below 1e-9). The model relaxes the audit: it omits the hpe cone caps and cold_end conditions and leaves tail frames free. So no frame regroup, coalescence or promotion recipe of any size can raise κ on these words. Lifting every frame to its greatest feasible value costs +3.8%. Annealing over commuting reorders (the
build_gate_moves.pyrule), followed by an exact frame re-solve, gave no gain in 11 restarts (ORDER-SEARCH.json). That is a sample, not a proof for all orders.Context for κ > 0.01. Jensen's inequality gives a ≤ −ln p / E_mass[ln(73/r)]. At the current deficit (2560 / 523264), a ≥ 0.01 needs a mass-weighted geometric-mean child rank of at least 44.7; today it is 3.66. At today's child ranks it would instead need a deficit of at least 15,425 (6.0×). Reaching it needs new scalar structure, not frame bookkeeping. About 1,700 of jp8's 2,512 rank-1 climbs are helper unit climbs.
Files.
research/frame-lift-search/contains the model, the LP/CP-SAT solvers, the order search,RESULT.jsonandORDER-SEARCH.json.tests/test_frame_lift_search.pychecks the lattice model on the in-repo #571 prefix word. There is also a one-line experiment-log link.Verification.
check.pyran on a freshcomplex-k492-owner-repair/verify.pyrebuild (Linux, Python 3.13) and reportsPASS_FRAME_ONLY_LP_OPTIMAL_FOR_SELECTED_PROVIDERS.python3 -m unittest tests.test_frame_lift_searchpasses. I did not runmake verify: no generator, certificate or selected-record file changed.Limits. HiGHS is a floating-point LP, not an exact rational dual certificate, and CP-SAT's
OPTIMALcomes without a proof log. The scalar program, helper count, dispatch, hosting and bit supplier are out of scope.