Skip to content

κ = 9.5424356568133e-4: seven-stage E8 suppliers with the complex idle climbs at halving degree two (+2.40 % over #373) - #375

Closed
DaysSky wants to merge 1 commit into
CrocSwap:mainfrom
DaysSky:research/e8-seven-stage-halving-two
Closed

DaysSky wants to merge 1 commit into
CrocSwap:mainfrom
DaysSky:research/e8-seven-stage-halving-two

Conversation

@DaysSky

@DaysSky DaysSky commented Oct 11, 2026

Copy link
Copy Markdown
Contributor

κ = 95424356568133/10¹⁷ ≈ 9.5424356568133e-4 (conditional). That is +2.40 % over #373 (9.3191395651209e-4), which this PR extends, and +9.00 % over #370.

The PR adds one self-contained package, research/e8-seven-stage-halving-two/, with its own workflow. No existing file changes except one .gitattributes line.

Change and mathematical scope

Everything is #373's: #370's E8 bit word and Sussman's E8 complex unit, both unchanged, both in the seven-stage bridged word B₃. There is one change, on the complex side.

What changes. #363 split the complex supplier's two longest idle climbs below m/2 (38 → 31 + 7, 32 → 31 + 1). It did this only to meet the half-shrink guard (2 · max child < m) of the inherited complex finite bridge. Here they are left whole. The largest complex child becomes 38 of m = 63, so one level no longer halves the size but two levels do: 63² = 3969 > 2 · 38² = 2888, i.e. halving degree two.

side layout max child / m coarse saving
bit (#370 word, #373 checks) B₃, split 27 / 56, degree 1 c = 968197503705007/10¹⁸
complex (Sussman's E8) B₃, unsplit 38 / 63, degree 2 b = 119394377245827/(125·10¹⁵) ≈ 9.55155e-4 (+2.40 % over the split 9.32783e-4)

The complex side binds. All 47 constraints of outer.assembly hold, the complex leaf cap itself is rejected, and the adjacent 10⁻¹⁸ grid point is rejected.

Why halving degree two is admissible. The inherited bridge (FINITE_BRIDGE.txt §4) uses half-shrink in exactly one place: "The complex child maximum below m/2 gives halving degree 1, while log2 W < 5208 < 10000", inside the external row coefficient A = 10000 + 9909 + 252 = 20161.

With halving degree t, the recursion depth is t·⌈log₂ n⌉ and the row term is t·log₂ W. The generalized guard does three things:

  • it computes the least t;
  • it charges t times the actual physical stock logarithm: 2·1903 + 9909 + 252 = 13,967 < 20,161, so A and the outer assembly are unchanged;
  • it keeps m ≤ 72 (the cover bound) and the completed-child induction gap (49·B > 0).

At t = 1 it is the original guard.

The repository already uses this generalization:

  • Paired cubes and shared completed cores for conditional kappa = 4.609169e-4 #144's integration review (research/pr-review-20261009/check_paired_cube_arithmetic.py): complex child 60 at m = 72, halving degree 4, row coefficient 4*2571+9909+252;
  • the copied-centers assembly (copied-centers-assembly.tex, research/copied-fixed-reversed/balanced_assembly.py): degrees 9 and 20, reserve D_j(e) = t_j⌈log₂ e⌉;
  • PR234 on the bit side: "The proper child ratio 5/6 requires halving degree four. The one-level weighted recurrence is retained; its histogram is not multiplied by four."

The moment equation is the one-level histogram either way.

Why not further. Unsplit complex B₄ prices at 9.5673e-4 but has m = 81 > 72. Unsplit B₅ needs degree 3 and prices lower. The bit side stays split because it does not bind; unsplit at degree 2 it would give 9.9123e-4.

What is checked

Every step of #373's verify.sh runs:

On the complex side certify_b3.py runs the guard three times:

The circuit binding is unchanged: Sussman's Lean data for wht_main_block_B2Ge8x regenerate byte for byte, and his replay accepts at 8762479.

The κ step reproduces #373's κ = 93191395651209/10¹⁷ with the split b₃, then gives 95424356568133/10¹⁷ with the degree-2 b₃.

Provenance: 142 files are identical to #370 (b7fe9cd), 4 to #363 (9df55da) and 7 to #373 (3ff87b5), recorded by git blob ids. The edited files are portable_complex.py (halving degree), certify_b3.py, verify.sh, provenance.py, README and NOTICE. The new file is pins-e8-b3h.json.

Open obligations

Validation

python -m pip install -r research/e8-seven-stage-halving-two/requirements.txt    # numpy==2.5.3 mpmath==1.3.0 sympy==1.14.0; g++ C++17 + Boost headers
bash research/e8-seven-stage-halving-two/verify.sh /tmp/e8-halving-two-verify    # about 4 min

Local result (macOS, Python 3.12 and 3.14), selected lines:

   B_3 formal columns PASS: all 1585 physical columns over F2 (dirty helpers) through 7 invocations, 12 twin bridges, terminal exchange; 12 omitted-bridge controls rejected
complex checks, halving degree two: B_3 unsplit PASS_FRESH_COMPLEX_LABEL_SCALAR_SPLICE_PRECISION | m 63, max child 38 (63^2 > 2 * 38^2), halving degree 2, rows 13967 < 20161, induction gap 49 B
PASS halving degree two: B_3 b = 119394377245827/125000000000000000 = 9.551550179666e-04 (+2.398 % over the split B_3, +9.005 % over B_2)
   regression: with the split complex b_3 the seven-stage bit word gives PR #373 kappa 93191395651209/100000000000000000
KAPPA = 95424356568133/100000000000000000 = 9.542435656813e-04 | 47 strict constraints positive, adjacent grid point rejected
PASS finite bill (E8, K = 3, m = 56): coefficient 57685376070645 (46 bits) < 2^80, q-power bound q^3137, payload prefix 60 bits < 104, delta_tau 37945757723910, reference route {'swap': 7}; all 120 port routes exact elementary programs, at most 77 factors, denominators [1, 2, 4] (powers of two: units modulo every odd q)
PASS conditional kappa = 95424356568133/100000000000000000 = 0.00095424356568133 (seven-stage bit word, complex-bound by the seven-stage E8 complex unit at halving degree two; bit coarse 968197503705007/1000000000000000000 = 0.000968197503705007 )

These are finite certificate checks only; the obligations listed above remain open.

Credits and AI disclosure

The halving-degree-two complex step and the package were prepared by DaysSky, assisted with Claude.

…, kappa 9.5424356568133e-4

PR CrocSwap#373's seven-stage E8 bit and complex suppliers, with the complex supplier's two longest idle climbs left unsplit
(max child 38 of m = 63, halving degree two: 63^2 > 2 * 38^2). The complex finite guard computes the least halving
degree t and charges t times the stock logarithm in the external row coefficient (2 * 1903 + 9909 + 252 = 13967
< 20161), keeping m <= 72; t = 1 is the original guard.

Complex b = 119394377245827/(125 * 10^15) (+2.40 % over the split B_3); complex-bound
kappa = 95424356568133/10^17 (+2.40 % over PR CrocSwap#373). B_2, the split B_3 and PR CrocSwap#373's kappa are regressions.
GamingPuzzled pushed a commit to GamingPuzzled/integer-mult-bounds that referenced this pull request Oct 11, 2026
…eded

The reviewed gen4 result itself treats even-coefficient payload ADDs as
identities over F2, and PR366's word carries even helper multiples in its
outputs over Z, so F2 column correctness is the accepted standard and
PR370 meets it. The earlier note calling it an open requirement was wrong.
The seven-stage composition is superseded by PRs CrocSwap#374, CrocSwap#375, CrocSwap#378, CrocSwap#380.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NM5QuNb8JPq4YxKRzxVodj
@Mister-Meeseeks

Copy link
Copy Markdown
Contributor

Thank you @DaysSky. This contribution is now retained on main in the scoped 100-PR review and contributor credits.

Contribution: Seven-stage E8 with halving degree two.

Review and limits: A changed precision/recurrence bill with explicit regression and guard checks, not merely parameter substitution in an unchanged theorem.

The complete original source, notices and relevant execution evidence are retained through the pinned source archive. The review distinguishes fresh local runs, source-bound historical Linux CI and prior exact-head review; it does not claim 100 fresh full mathematical audits. Closing this historical PR as reconciled. This preserves parallel and cumulative credit without replacing the selected frontier or promoting priced research targets to completed constructions.

Reviewed head: 79874623cf86d92325c26ccafc31413d12e9d248. Publication: 4040a0f46d67b41c36a472a7cd4af791fd4c36cc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants