Triple-core lockstep with conservative data accounting: candidate κ = 4.50198447040e-4 (+8.85% vs #138)

[DanieleCorso]

Summary

This draft explores a triple-core first-stage lockstep construction, combining PR #137's completed-core scratch sharing with a synchronized physical-frame execution strategy inspired by PR #132.

The finite arithmetic candidate reaches:

κ = 0.00045019844704

This represents approximately +8.85% over PR #138 (κ = 0.000413596646966) and exceeds the 4 × 10⁻⁴ target.

Status: Candidate only. The combined physical execution theorem remains unproved.

Methodology

The construction starts from the frozen PR #137 padded three-stage cover, retaining its audited local complex producer, compensated birth-cut reuse, source gauges, and weighted bit supplier.

The proposed optimization is to execute the auxiliary and center frame transitions of three mutually orthogonal 24-dimensional cores in lockstep during the first stage.

Under a valid shared physical implementation:

• Three rank-r local transitions are replaced by one rank-3r transition.
• The second and third stages remain unchanged.
• Source and target data operations remain independent.
• Completed auxiliary tails, inverse operations, padded data finishes, scalar reserves, and finite routers remain accounted for.

Importantly, the numerical analysis does not assume that data operations can be merged for free.

A conservative positive moment correction covers all nonmergeable data fronts, using their exact rank mass and rational upper bounds for logarithms and exponentials.

Conditional finite results

Quantity| Result
Ambient dimension| 72
Persistent streams per cell| 91,935
Recursive rank mass| 6,612,144
Rank deficit| 7,176
Largest child| 69
Conservative complex saving| 0.000468719485
Retained stopped bit saving| 0.00045060418316
Candidate κ| 0.00045019844704

The finite arithmetic calculation checks the characteristic moment, coupled assembly, all 47 strict constraints, seven margins, and next-grid rejection.

Reproducibility

python3 research/triple-lockstep/certificate.py

The verifier builds on PR #137's pinned source inventory and recomputes the proposed child histogram, conservative data-moment penalty, and final finite assembly.

Outstanding physical proof obligations

The numerical improvement depends on a new synchronized three-core execution that is not yet independently established.

In particular, the following still require proof and verification:

• A literal joint physical compiler for the three cores.
• Correctness for arbitrary dirty scratch states.
• Preservation of compensated readouts and source-gauge invariants.
• Exact signed phases, inverses, and reflected execution.
• Cross-core noninterference and complete all-column replay.

PR #137 establishes sequential completed-core reuse, but this does not automatically establish the proposed overlapping lockstep execution.

Until these obligations are discharged, the displayed κ is a finite arithmetic candidate, not a certified new multiplication bound.

Attribution

This work builds on PR #137 (eumemic), PR #132 (ikeboy), PR #130 (icekylinx), PR #124 (jamesyc), and their original source contributors.

The combined research hypothesis and conservative numerical analysis were prepared with OpenAI assistance. All inherited source attributions and licenses are retained.

This PR is intentionally submitted as Draft pending full physical verification and independent review.

[Swapnil-jain]

Heads-up on the lockstep step: this has the same obstruction that led to #132's retraction (counterexample: #132 (comment), confirmed by @ikeboy).

Running the three cores' auxiliary/centre frame transitions in lockstep means all three cores' live data are on the shared stream at once. Each merged rank-3r transition then also transforms the other cores' live contributions, and each core's reads pick them up. #137's sequential schedule avoids this because every core completes its dirty cancellation before the next starts. That is the property lockstep gives up. Keeping the data operations separate doesn't help, because the aux values the frames act on already contain each core's data.

Unless the shared physical implementation keeps the cores' live values apart (which a frame-label slice does not), the merge looks limited to boundaries between consecutive cores. The small exact replay in the #132 thread should adapt directly to a three-core first stage if you want to test it.