Research: CK dyadic ladders save 13,770 / 67,146 primitives (no new kappa)

research/complex-ck-dyadic-ladders/CLAIM.md

@@ -0,0 +1,58 @@
+# Complex-supplier claim, seed 36
+
+- Contributor: @24kHandsome1201, with substantial OpenAI Codex assistance.
+- Assignment: OS-random seed **36**, drawn 2026-10-13 at 04:52:45 UTC.
+- Base: `66849e1475c930fd7732b1a0067ffee7e1e95f60`.
+- Track: complex supplier. Seed parity selects the selected CK provider.
+- Scope: contiguous scalar additions with an unchanged source, a common frame,
+  non-unit dyadic coefficients, and a common odd numerator part. Reuse the
+  coefficient-work stream by halving/doubling between different magnitudes.
+- Method: exhaustive scan of both pinned CK event streams, preserving event
+  order and every non-scalar boundary. Compare full primitive costs before
+  implementation, then check arbitrary-input maps and prefix bounds exactly.
+- Deliverable: a finite circuit result, executable verifier, pinned sources,
+  complete run census, negative controls, proof and attribution. No new kappa.
+- Planned finish: 2026-10-13 05:35 UTC, including final verification/handoff.
+
+## Task selection and overlap
+
+Three candidates were considered: (1) variable-coefficient work reuse,
+(2) raw coordinate-factory resynthesis, (3) fixed-frame CK cleanup fusion.
+Candidates 2 and 3 overlap #681 and #719. Candidate 1 extends the common-
+magnitude reuse investigated in #722 to varying powers of two, on CK and
+in both orientations. The selected runs must contain a genuinely changing
+magnitude with a cheaper scale transition; equal-only runs are excluded.
+
+The initial scan covered 544 open PRs through #725. The review ledger and
+selected #626 construction/review were inspected. #696 changes the single-
+macro primitive lowering, #723 changes JP8 numerator preparation, and #698
+concerns B-frame optimality. None of those patches is imported here. Savings
+will be counted directly against the selected program, with a separate
+constant-magnitude-only comparator; no unverified additive savings claim.
+
+There was no pinned sprint coordination issue. The only open issue found was
+#650 requesting Discussions, so the claim is recorded here and no reservation
+issue/comment is posted. Work is bounded to this one provider and mechanism.
+
+The full finite domain is scanned, with no sampled search or solver timeout.
+Source code and proofs are produced by one Codex agent; no independent human
+or delegated-agent review is claimed.
+
+## Result update
+
+743 varying runs pass exact replay: 13,770 forward and 67,146 backward
+real-component primitives saved. The incremental savings beyond constant-
+magnitude sharing on the same blocks are 6,012 and 12,596. The 280 backward
+runs occur in zero-frame preconditioning. All old prefix envelopes match.
+
+The next overlap refresh reached #751 and found concurrent #739's JP8
+forward-cleanup rescaling. The README/NOTICE credit its mechanism. This CK
+contribution adds a distinct provider/phase domain and independently produced
+716+9 full-program column evidence plus 11,610 local basis checks. No general
+priority or combined-savings claim is made. See VALIDATION.md for submission
+status and the final refresh.
+
+The final pre-submission metadata refresh reached #767 and found #755's
+equal-magnitude JP8 reuse in both orientations. README/NOTICE credit its
+backward-phase coverage. This package's narrower contribution is separately
+verified CK varying-magnitude reuse; no phase-priority claim is made.

research/complex-ck-dyadic-ladders/NOTICE.md

@@ -0,0 +1,63 @@
+# Attribution
+
+Prepared for **@24kHandsome1201** with substantial **OpenAI Codex assistance**
+in task selection, circuit development, mathematical argument, implementation,
+verification and writing. One AI agent performed this work. No delegated-agent
+review or independent human review is claimed. New work is Apache-2.0 under
+the repository's root LICENSE.
+
+The input is the selected #626 CK provider on repository base
+`66849e1475c930fd7732b1a0067ffee7e1e95f60`. Chafik Boukhalfa / chafreaky
+provided #626's packaging, owner repair and independent checks, at reviewed
+head `660de893d27bb7abd1d5b01b1640207528a5c851`. Jeremy Kothe / jeremykothe2
+and his disclosed Claude Code research agents supplied #622's K-triangle
+construction at `f69477f4f6d3c7eb1f740b166881bffed4ffa9f6`, on the credited
+complex-provider lineage.
+
+Credit icekylinx for the direct-delivery/factory construction and scalar
+emitter/replay architecture; DreamingOfClouds for the retained native and
+cold-helper work; Dugongue for earlier modules and rank-sector work; eumemic
+for the retained #543 bit supplier; Rohan Arun for the #559 recurrence
+correction; and all predecessors identified by the selected review and
+`research/complex-k492-owner-repair/NOTICE.md`. Their original notices,
+licenses and AI-assistance disclosures remain in the unchanged source tree.
+The explicit reference primitive recipe implements the binary-Horner rule in
+the pinned `hpe_emit_local.py`. The sparse scalar and positive-envelope replay
+follows the mathematical semantics documented in the pinned
+`hpe_audit_local.py`, with a new primitive interpreter and block checker.
+
+Concurrent conceptual predecessor: @ellipsi2's #722 at
+`a0766ab0fab379e1997fadc3ca157578d57986c1`, prepared with disclosed OpenAI
+Codex assistance, shares identical coefficient preparation in JP8 cleanup.
+We extend reuse to changing magnitudes through exact scale transitions, on
+CK and both orientations, and separately quantify that incremental benefit.
+No #722 code or certificate is imported.
+
+Concurrent #739 by Jeffrey Cox / @namredips, with disclosed OpenAI Codex
+assistance, at `abb9825202dba6f9bc95c7df8d12d86088fdff1a` independently
+publishes the same varying-magnitude rescaling idea for JP8 forward cleanup.
+It was discovered in the in-progress overlap refresh. This package makes no
+priority claim for that mechanism; its new evidence concerns CK, both
+orientations, and particularly zero-frame preconditioning. No #739 code is
+imported and its JP8 figures are not included in our CK figures.
+
+Final pre-submission refresh found @taizaki69's #755 at
+`a1dd9f819102c40e0b5e4a75215cf69ee864f480`, prepared with OpenAI Codex
+assistance. It covers equal-magnitude JP8 reuse in both orientations,
+including zero-frame preconditioning, with #696's copy initialization.
+Credit that independent phase extension; no priority for backward reuse is
+claimed. Our CK varying-magnitude construction uses the original Horner
+initialization and imports no #755 code or counts.
+
+Related work inspected: #696 (`5a3f983715027c4fd83f50bc9001d4b18463bed1`),
+#723 (`d3bc41b87fc7d23f50d064a0f06f1a89e3ab02a7`),
+#681 (`fdc2e4f3c6825530b02143b30deab5de10209479`),
+#719 (`a3d9c0aa0a16b68b1f4dd064671ad018013e6dd4`) and
+#698 (`ab78f797cffcbeddbb17a7eb069741085ffe3351`).
+They are contextual comparisons, not runtime dependencies. Combined savings
+with those alternative circuits have not been verified.
+Later refresh also inspected #734 at
+`ba76ba3321d000c8996b0b254bcf0d7260e1bbb6`, #750 at
+`b6d6934092c063ab2575ebee00f48bbc7b1c9d82`, and #751 at
+`66de747e597cc1509edaf486d9df8a46061164e8` for single-macro recoding,
+live-scale relocation and JP8 common-target fan-in respectively.

research/complex-ck-dyadic-ladders/README.md

@@ -0,0 +1,210 @@
+# Varying dyadic coefficient ladders in the selected CK supplier
+
+The selected CK scalar program repeatedly prepares different powers-of-two
+multiples of an unchanged source. This package retains one coefficient-work
+value across contiguous additions and halves/doubles it when that costs less
+than clearing and preparing the next value. It changes **743 runs containing
+10,124 additions**, with exact arbitrary-input equivalence in both orientations.
+
+**Finite local circuit improvement / research note; no new kappa.**
+
+| CK scalar program | Selected primitive count | Ladder count | Saved | Reduction |
+| --- | ---: | ---: | ---: | ---: |
+| Forward | 224,938 | 211,168 | 13,770 | 6.12% |
+| Backward / inverse-transpose | 224,986 | 157,840 | 67,146 | 29.84% |
+
+Counts are real-component primitives per local program invocation. Every
+source addition, work initialization, halving/doubling, signed target update
+and final work clear is included. These are circuit counts, not timings.
+The two directions execute their own compiled circuits and are checked against
+their own arbitrary-input maps; reversing the forward implementation is not
+assumed to produce the backward implementation.
+
+## Reproduce
+
+From the repository root, with Python 3.11+ and no external packages:
+
+```sh
+python3 -I -B research/complex-ck-dyadic-ladders/verify.py
+python3 -I -B research/complex-ck-dyadic-ladders/check_columns.py
+```
+
+The check is offline and writes nothing. Expected final line:
+
+```text
+PASS_CK_DYADIC_LADDERS blocks=743 saved=13770,67146 columns=716+9 controls=13
+PASS_CK_LADDER_COLUMNS blocks=743 columns=11610 missing_clear_rejections=743
+```
+
+`RESULT.json` records every half-open **zero-based emitted-event interval**,
+source, frame, event hash, complete counts, and exact work-prefix bounds.
+The original event streams are retained in the repository's selected #626
+evidence. `SOURCES.json` pins their full decompressed payloads, their native
+word, selected SPEC, receipts and original emitter/auditor. Gzip header or
+compression-level changes do not invalidate an otherwise identical payload.
+The code checks the additional binding from the native/program hashes to SPEC.
+
+An optional `--write-receipt /new/path.json` writes the same regenerated receipt
+to a new file with exclusive creation. Existing files are never overwritten.
+Default verification compares every field of the freshly computed receipt.
+
+## Exact local construction
+
+Consider consecutive operations, in their existing order,
+
+```text
+t_i += q_i * s
+```
+
+The source `s` is never a target in the run. All operations have the same
+frame, every `q_i` is nonzero and non-unit, and each ratio
+`|q_(i+1) / q_i|` is a power of two. We restrict this contribution to live
+registers `L`; center registers and every non-scalar event split the run.
+Maximal runs containing no profitable change of magnitude are not selected.
+
+Let `P(q)` be the number of real-scalar operations used by the original
+positive binary-Horner preparation of `|q|s`, including its initial clear:
+
+```text
+P(q) = 1 + (bit_length(a)-1) + popcount(a) + log2(b),
+where |q| = a/b in lowest terms.
+```
+
+The original addition costs `P(q)+2`: preparation, signed accumulation, clear.
+After accumulating the previous coefficient, either retain the work value and
+shift it by `k = log2(|q_next/q_previous|)`, or execute the original
+clear-and-prepare transition. The transition cost is therefore
+
+```text
+min(|k|, 1 + P(q_next)).
+```
+
+The full run costs `P(q_0) + number_of_targets + 1` plus those transition
+costs. The real-component invoice multiplies this count by two. No leading
+copy shortcut, signed-digit preparation, reordered target updates or new
+scratch register is used.
+
+For example, forward events `[18860,18863)` read register 470 into registers
+655, 97, 656 with coefficients `-2`, `-1/4`, `-1/2`, all at frame 1. Prepare
+`2s`, accumulate, halve three times, accumulate, double once, accumulate and
+clear. This costs **22 real-component primitives instead of 32**.
+
+### Boundary map and prefix proof
+
+The initial clear removes any incoming coefficient-work value. Inductively,
+the work value at update `i` equals `|q_i|s`: preparation establishes the first
+value, a power-of-two transition establishes the next, and a reset uses the
+original preparation. The signed update is exactly the original target update.
+Because the source is unchanged, repeated targets are allowed. Final clearing
+gives the original block boundary for every live register and arbitrary initial
+private work.
+
+During a scale transition, the work magnitude lies between its two endpoint
+magnitudes. Both endpoint values occur in the original binary-Horner traces.
+The original preparation for a normalized coefficient `a/b` reaches `as`,
+and `b>=1`. Thus every new work prefix is bounded by the original run's
+maximum `max(a_i)|s|`. Target writes retain their original order and values,
+so no new target prefix occurs. The source and all other registers are fixed.
+The verifier checks the normalized work value at **every ordered target
+write** and checks every intermediate work value against this bound.
+
+The fresh full-program positive-envelope replay gives exactly the original
+bounds: `920709848294` forward and `146068000389976309073/32` backward. Both
+remain below the inherited 192-bit local allowance. This preserves the
+existing numerical envelope; it does not establish an all-size tape theorem.
+
+## Coverage and relation to concurrent work
+
+The OS seed is 36; its parity selected CK. Both 27,256-event streams are
+exhaustively scanned. There is no sampled parameter search or timeout.
+An independent adjacent-edge census checks maximality, complete coverage and
+the per-run cost formula without calling the circuit's grouping functions.
+
+| Orientation | Selected varying runs | Changed additions | Savings with equal-magnitude reuse alone on these runs | Additional saving from varying magnitudes |
+| --- | ---: | ---: | ---: | ---: |
+| Forward | 463 | 2,275 | 7,758 | 6,012 |
+| Backward | 280 | 7,849 | 54,550 | 12,596 |
+
+All 463 forward runs are in `full_frame_cleanup`. All 280 backward runs are
+in `zero_frame_precondition`, an additional phase outside the cleanup-focused
+scope of #722 and #739. The backward source remains fixed through
+each run just as in the forward construction; no transposition shortcut or
+common-target fan-in rewrite is used.
+
+This credits and extends the same-magnitude reuse idea in
+[#722](https://github.com/CrocSwap/integer-mult-bounds/pull/722), which studies
+JP8 cleanup. The comparator above is freshly constructed on these exact CK
+runs; it is not #722's JP8 result. Equal-only maximal runs are excluded, making
+the varying-magnitude contribution explicit. Its incremental saving is
+**18,608 real primitives across the two orientations**.
+
+While this implementation was being verified, [#739](https://github.com/CrocSwap/integer-mult-bounds/pull/739)
+published the same power-of-two rescaling mechanism for **JP8 forward cleanup**.
+Credit Jeffrey Cox / @namredips for that concurrent contribution. This package
+adds separately implemented **CK coverage in both orientations**, including
+the zero-frame preconditioning phase, exact bound preservation and a fresh
+11,610-column block verification. It claims no priority for the general
+rescaling idea. #739's JP8 counts and restricted cleanup search are not
+combined with the CK counts above.
+
+The final pre-submission scan also found
+[#755](https://github.com/CrocSwap/integer-mult-bounds/pull/755) by @taizaki69,
+which independently covers JP8 equal-magnitude sharing in both orientations,
+including backward preconditioning, combined with #696's copy initialization.
+That broader phase coverage is credited. The present package covers CK and
+varying magnitudes under the original binary-Horner preparation. It makes no
+priority claim for backward-phase reuse, and imports no #755 code or counts.
+
+[#696](https://github.com/CrocSwap/integer-mult-bounds/pull/696) changes the
+single-macro preparation and unit cases; [#723](https://github.com/CrocSwap/integer-mult-bounds/pull/723)
+uses signed-digit JP8 numerators; [#681](https://github.com/CrocSwap/integer-mult-bounds/pull/681)
+resynthesizes a raw factory word. Their implementations are not imported and
+their reported savings are not added here. [#719](https://github.com/CrocSwap/integer-mult-bounds/pull/719)
+rules out specific CK macro-pair replacements; this retains every scalar macro
+and changes its internal coefficient-work interface. [#698](https://github.com/CrocSwap/integer-mult-bounds/pull/698)
+studies fixed B-frame costs. None is a dependency of this replay.
+Concurrent [#734](https://github.com/CrocSwap/integer-mult-bounds/pull/734)
+changes single-macro signed-Horner preparation;
+[#750](https://github.com/CrocSwap/integer-mult-bounds/pull/750) relocates a
+CK live-register scale; [#751](https://github.com/CrocSwap/integer-mult-bounds/pull/751)
+uses a JP8 backward common-target reverse-Horner construction. They are
+distinct from the unchanged-source CK runs here. No combined invoice is claimed.
+
+## Verification and scope
+
+- Sparse exact rational replay checks both original and lowered scalar
+  projections on **716 live input columns**, including all 492 dirty helpers,
+  plus **nine independent private input columns** for eight centers and work.
+  Final centers/work are zero. Every live output matches the required shear.
+- Every changed block is separately checked for source invariance, common
+  frame, ordered target writes, exact coefficients, work clearing and prefix
+  domination. The checker does not call the constructor's preparation or
+  transition logic. Full-program primitive costs and positive prefix bounds
+  are recomputed and compared with the pinned selected receipts.
+- A separate flat-vector, column-oriented interpreter in `check_columns.py`
+  checks all **11,610 touched-register/private-work basis cases** across the
+  743 blocks. It also rejects omission of the final clear in every block.
+  It shares only the candidate circuit constructor; it does not import the
+  normalized proof checker, sparse interpreter or prefix machinery.
+- Thirteen controls reject missing initialization/final clearing, wrong scale,
+  sign, target order, undercharging, endpoint-neutral prefix inflation, frame
+  or source changes, source writes, bad coefficient domains and phase crossing.
+- Every non-scalar event remains at its existing boundary. The original paid
+  child histogram is recounted in each orientation. This package uses the
+  existing selected frame/wrapper evidence; it does not regenerate the native
+  provider or reprove the Clifford/hosting layer.
+
+The coefficient stream is clean at each fused-block boundary. Intermediate
+original scalar-macro boundaries inside a block no longer require a clear;
+the new block contract explicitly checks that no frame change, recursive call,
+adapter, center lifetime event or other consumer is crossed. A production
+emitter must adopt that contract and regenerate its invoice/admission receipts
+before using these lower counts in an accepted supplier. That integration is
+outside this isolated research package.
+
+The scalar word, native frames, helper count, recursive profile and selected
+kappa `51110230636731/31250000000000000` are unchanged. No optimality,
+practical speedup, new asymptotic exponent or formal multiplication theorem
+is claimed. Uniform compiler/common-label/mutable-basis realization,
+whole-call hosting, precision/tape/recovery, bit-supplier and analytic-transfer
+obligations remain inherited. See `NOTICE.md`, `CLAIM.md` and `VALIDATION.md`.