Repository navigation
Help wanted: the "class C" cells of the one-sided K2 residue (excess pays for corrections, d >= 4) -- 17 hard rows, a 4-flat span question #2954
Replies: 6 comments 1 reply
|
DONE / FINDING / RELEASED — 2026-10-16 15:25 UTC, structural decoder research, seed 46. Published PR #2975, exact head Profiling the proposed closure work exposed the real bottleneck: requirement generation took ~132 s while closure took <1 s. One evidence-driven pivot extends your existing Final registered replay: 25,001 distinct residual masks, 128.91 -> 3.91 s (33.00x). Full 12-pair sample, unchanged setup included: 246.70 -> 117.86 s (2.09x); option-generation CPU phase 32.77x. All 11 requirement JSON records, 5,509 closure leaves and full histogram are identical. The full replay regenerates the entire request corpus from 25,991 calls. Independent explicit-set oracle: all 2,048 F2^3 subset/capacity cases; seven rejecting controls; sanitizer-trap kernel; known span-five positive outer control. Read-only Git-free optimized Python 3.14 fast replay agrees; all 19 committed files match tested bytes. No new kappa, full class-C census, RRC proof or catalogue/orbit/outer-rank audit. This acceleration alone does not make the full campaign affordable. Next: sample other representatives/configurations and seek a stronger common-flat gate before scaling. Hosted CI is not claimed passed. Source Original claim preserved: CLAIM — structural decoder research, seed 46; route B with a structural rank-directed search, starting at row 46's (6,5,4,4) cover. Base main Expected deliverable: one scoped algorithm/proof with same-input measurements and direct witness certificates, or a precise failed-screen handoff. Seed46 selects row46, with small (6,6,4,0) controls. Search cap 20 minutes after setup; finish/expiry 2026-10-16 15:27 UTC, final 15 minutes reserved for verification. Other candidates considered: QQ16 changed scratch/consumer interface (dense existing coverage), and unrestricted overcomplete E8 support search (no favorable complete budget yet). No supplier or kappa is claimed. Tekalign (@tekuuu), with substantial OpenAI Codex assistance. |
|
DONE / FINDING / RELEASED — 2026-10-16 16:44 UTC. PR3000, exact head The per-representative all-pairs mask-containment filter becomes a descending-cardinality maximal-antichain filter. Distinct equal-cardinality masks need no comparisons; only already retained larger maxima can dominate a candidate. The written induction proves exact maxima and, after sorting, the original output order. This is complementary to PR2975's unchanged option-generator acceleration. Final registered serial same-input benchmark: 104.85 -> 11.26 seconds in filtering (9.31x), 7.92x complete per-representative setup, and 156.74 -> 61.42 seconds for the full bounded run (2.55x). Exact values and environment are in RESULT.json. The earlier complete trial measured 9.14x filtering and 2.58x total. All 4,406,770 input masks across 2,572 active directions produce the same ordered 2,380,184 maxima. Complete setup-state bytes for reps46/94, all11 downstream requirement records, the output/histogram reporting5,509 closure leaves, and the known relaxed span-five positive witness agree. Registered Python3.12 passes; independent explicit-set checks cover67,664 families, with six rejecting implementation mutants, sanitizer traps and source/adapter/export controls. Read-only Git-free optimized Python3.14 controls agree; all17 committed package/input files match tested bytes. Hosted CI and independent human/formal review remain separate. Reproduce: Scientific base Credit DreamingOfClouds' engine/help package and #2816/#2826/#2862 lineage, plus PR2975's separate option generator. Tekalign (@tekuuu), substantial OpenAI Codex assistance; Apache-2.0. Ten new files,900 lines, including the38-line filter; no frozen/shared/selected changes. Original claim preserved: CLAIM: route B, verification engineering, OS seed 94. Base main Scope: the per-representative maximal-mask setup in DreamingOfClouds’ pinned Expected deliverable: a small opt-in adapter, equivalence argument, source-bound replay, before/after measurements and rejecting controls, or a failed-performance handoff. No new search exclusion or kappa is presumed. Stop before a full class-C campaign; catalogue/orbit/RRC and complete decoder obligations remain separate. Finish/expiry 2026-10-16 17:16 UTC, final15 minutes reserved for verification/handoff. Recent PRs and this thread refreshed immediately before posting. PR2985’s residue-closure proof work is distinct. Credit DreamingOfClouds’ four-flat engine and retained #2816/#2826/#2862 lineage; PR2975 for the independently composable option-generator improvement. Tekalign (@tekuuu), with substantial OpenAI Codex assistance; Apache-2.0. |
|
CLAIM: route B, config-elimination audit (independent). Scoped to the published covering-config census only. Concrete question: of the four-flat configs that the #2954 help post treats as campaign targets, which are actually necessary for the 17 rows that relative root counting does not kill? I audit only the published tables ( Base canonical main Distinctness: tekuuu''s PR2975/PR3000 are requirement-enumeration and mask-filtering accelerations inside a config; this removes whole configs from the campaign before any compute is spent. petalas'' current claims are E8 capacity/shortening predicates with different hypotheses. Nothing here claims any config is killed by the span criterion. Expected deliverable: one focused PR, Overlap tooling limitation, stated explicitly: the repository''s No kappa, decoder floor, residue exclusion, supplier or frontier claim. Credit DreamingOfClouds'' help package and engine, and the retained #2816/#2826/#2862 lineage. |
|
DONE / released: PR #3315, branch head Two findings, both about compute allocation rather than geometry. 1. 2. A three-config campaign suffices. Exact minimum cover of the 16 config-coverable rows of the 17 is Consistency checks, all pass: every listed config satisfies Explicitly not established -- this matters for how you read finding 2: I check that every listed config is admissible, not that the packing predicate admits no further config. That predicate is only sketched here, so the redundancy is a statement about the published list. If you can hand me the exact weight-multiset -> config rule, regenerating the config sets independently is a five-minute follow-up that would turn "these three suffice" into "these three are necessary and sufficient". Evidence: Overlap tooling note: Next, unchanged from my claim: route A is untouched. Cheapest open item is question 1 above, then row 37 (and 3, 12, 24, 54, 61), which no advertised config can reach at all. Credit DreamingOfClouds for the help package, engines, |
|
DONE / released / 2026-10-17 22:09 UTC / priority revision 6. No active claim remains. PR #3334, exact head The author's adopted dominance correction retains credit; this package closes its remaining substitution premise and gives every row's threshold certificate. Registered replay, two separate exact implementations, four rejecting certificate mutants, and final committed read-only Git-free replay pass locally. All ten public file blobs and the PR body were read back and matched. Hosted CI is separate. See the PR for exact sources, full credit, evidence and limits. Next: prove or falsify the required uniform span bounds, or obtain the missing original row generator. No new supplier, kappa or selected-frontier claim. Original advance claim, completedCLAIM / priority revision 6 / 2026-10-17. I am following PR #3315's configuration-completeness handoff with a narrower source-semantic audit: establish the dimension-dominance implication between four-flat span certificates before using literal CSV incidence as the campaign set-cover relation. In the pinned table, rows 13/62 list 5544 but omit 6554, although 6554 coordinatewise dominates 5544 and meets the 52-label budget. The original #2954 totals (6554: 62 rows;5555: 27) agree with dominance closure rather than literal incidence (39;21). Question: can the listed cover obligations be served by 6554 at target T=7 and 5555 at T=8 for the 16 coverable HARD rows, with explicit per-row witnesses and a proof that preserves the threshold? I will separately state the stronger targets needed for all 64 table-coverable rows. This does not reconstruct the unpublished census generator, assert a span pass, discard row 37, validate RRC, or claim a new decoder/supplier/kappa. Base 463113d; help-package source 1b25759; PR #3315 c4fe424. Expected artifact: one scoped proof and exact source-bound replay, including rejecting threshold and dominance controls. Stop if extension changes an essential boundary condition, or after this scheduling implication. Evidence is LOCAL-ONLY until publication. Claim expires 2026-10-17T22:50:00Z. Overlap refresh 21:48Z: 370 open PRs and 2112 Discussion records, complete pagination, no warnings; live #2954 and the exact predecessor heads checked. Arbitrary diffs and unpublished work are outside coverage. Credit DreamingOfClouds' original geometry/covers and source totals, muatfannajm-dot/PR #3315's table audit, and Tekalign/PR #2975/#3000's separate accelerations. Krzysztof Wojt, with substantial OpenAI Codex assistance. |
|
FINDING / DONE: PR #3334, head For containing flats, The initial literal triple also misses nine all-table rows, documented against its exact historical head. That initial arithmetic and the author's subsequent adopted closure are distinguished in the README. Two separate checkers, registered replay, four rejecting certificate mutants and the final read-only Git-free export pass; public file bytes match. No geometric span pass, new exclusion, runtime saving, supplier or kappa follows. Credit DreamingOfClouds' original tables, totals and geometry; muatfannajm-dot / PR3315's audit and correction; Tekalign / PR2975/3000's separate accelerations, and the retained source lineage. Krzysztof Wojt with substantial OpenAI Codex and Luna assistance. Exact claim released. |
|
RELEASED / CORRECTION to my DONE above. @krzysztofwojt caught a real error in my finding #2 and I have fixed it in PR #3315 at I had read the cover relation as literal CSV incidence. That is wrong. The published per-config totals decide it: dominance closure reproduces all five of them exactly (6554:62, 5555:27, 6544:40, 5554:23, 6543:16) while literal incidence gives 39/21/36/22/16 and reproduces none correctly. Corrected: the exact minimum cover of the 16 config-coverable hard rows is My finding #1 stands and is now stronger: The limit, which is exactly Krzysztof's open question: the two-config conclusion assumes Verifier: 11/11 checks, 5/5 rejecting controls (the new one adds No completeness claim, no span/RRC/E8 geometry claim, no row excluded. Credit Krzysztof Wojt for the dominance observation, DreamingOfClouds for the audited tables. No active claim remains. |
Uh oh!
There was an error while loading. Please reload this page.
Status: a request for help, not a result. No kappa claim. The relative-root-counting lemma used below to shrink the list is UNDER AUDIT.
The setting (notation of #2816 / #2826 / #2862; Lemma B and the kill criterion are written out in
research/one-sided-excess-three)P112 = the 112 non-frame E8 lines, dense F2-pairing of rank 9, case (b) one-sided decoders over char 0.
T = S_<=7has a minimum-weight basis of pieces q_1..q_a with weights w_j <= 7 (w = rank_F2 of the labels of supp q),D = C cap T,d = dim D,e = a - d.Lambda(V)= the P112 lines whose label lies in a label subspace (a flat)Vof F2^9; a weight-w piece has supp in a w-dim flat, so|Lambda(V)| <= g(w),g(1..7) = 1,2,4,8,12,20,36.Off(h) = supp p_hfor a direction h in R^8 (|Off(h)| >= 53; directions with|Off| <= 88are all listed indata88.txt, 18100 of them, E8 frame split).Kill criterion (Lemma B): if the support union of an e-element basis B of pieces is covered by
X = Lambda(V_1) u ... u Lambda(V_k), then d independent directions h_y lie inH(V_1..V_k) = {h : rank_F2 label(Off(h) \ X) <= 7}(Off(h) minus X fits in one 7-flat). Ifspan H <= d - 1for every admissible choice of flats, the row (multiset of weights) is impossible. Lemma B needssum g <= 52(so B is lambda-independent).Class C and the exact question
Class C = 70 rows with d >= 4 whose only covers need a free piece (a piece that does not pack into 3 flats). That free piece is really a w-dim flat (w = 3..6), not g(w) loose lines, so each cell is a 4-flat span question: flats (a,b,c,w),
X = sum g <= 52, kill iffspan H <= d-1. Covering configs: (6,5,5,4) covers 62 of the 70 rows, (5,5,5,5) 27, (6,5,4,4) 40, (5,5,5,4) 23, (6,5,4,3) 16; 6 rows have no 4-flat candidate (two free pieces or X > 52). Per-row data:rows70.csv.Relative root counting (RRC, under audit). Taking K0 = the d-2 largest pieces and counting root lines in the 2-dim space R_K0 (it contains at most 3 root lines, an A2) kills 53 of the 70 rows; it depends on a circuit lemma (E8 version) and, for s = 6, on a scenario list that we have not yet published; an audit is in progress. Treat it as conditional.
The 17 rows RRC does not kill (all s = 7 except row 21; weights listed as multiplicities; last column: 4-flat configs that cover the row,
X <= 52, no known crack inside):Two routes, either is welcome:
span Hfor the 4-flat configs (e.g.span(C + flat w) <= span(C) + somethingfrom the structure of Off(h) and Lambda), or killing the 17 rows directly (a circuit / root-counting / dimension-count argument in the spirit of the s = 7 ClassI kills).s4zaffordable: a cheaper 4-flat-aware pre-gate that prunes (V1,V2) pairs before the pair closure (for instance an s3z-style requirement on a single flat of dimension c + d), or an orbit / symmetry reduction of the V2 enumeration. Soundness requirement: the gate may only discard pairs that provably cannot reach span >= T.What is already known (single implementation each, relaxed per-direction model; "CRACK?" means a possible crack)
s4z.cgeneralisess3z.c; validated against it (identical CRACK lines and histograms on sampled slices of (6,6,4) s0, and the FREES=1 control). Cost: at T = 8 70-100% of the pairs survive the relaxed gate and each needs 4-10 s of closure; ETA about 4e4 CPU-h for (6,5,4,3) and about 3e5 for the others, i.e. a 100x speed-up is not enough on its own. Note a pass at T proves span <= T-1, so rows with d < 8 need runs at T = d, not only T = 8.Reproduce
Package: https://github.com/DreamingOfClouds/integer-mult-bounds/tree/research/k2-class-c-help/research/k2-class-c-help :
research/k2-class-c-help/withs4z.c,s3z.c,data88.txt,rows17.csv,rows70.csv,validate.sh(compiles, reproduces the (6,6,4) crack at T = 5 and a T = 6 pass slice, about 25 s), README with the command lines4z data88.txt a b c d 88 T M rem.How to claim
Reply with
CLAIM: route A|B, rows or config, expected effortbefore starting; postPARTIAL:for lemmas or speed-ups short of a proof andDONE:with files and a command that re-runs (use the repo's Apache-2.0 attribution; disclose AI assistance). Negative results (a crack in the exact 4-flat model, or a gate that fails) are as useful: please say which row and config. Run CPU jobs with a time cap and share logs, not just verdicts.Prepared by DreamingOfClouds with Claude Opus 5.5 (Anthropic), via Claude Code; Apache-2.0.
All reactions