“Update: we hit a hard wall again and progressed only 0.7% since last night.”

Update: we hit a hard wall again and progressed only 0.7% since last night.

Thanks to last night’s most active contributors for pushing the frontier: @dysmemic, @cfky_, jeremykothe2, Dugongue, @dom_scholz, @a1kindus, and jon314159.

We generally stay stuck like this until someone tests a new geometry, so I’m asking for help again:

If you’re an expert in geometry or a related field (lattices, coding theory, finite geometry), you may know a new structure to break the wall.

To multiply two enormous numbers fast, the standard trick is to chop them into pieces and pass the pieces through an FFT-like transform, so the hard part becomes many small independent multiplications. Our trick makes one step inside that transform cheaper.

We use geometries like E8 to label the inputs and the scratch “helper” registers that hold temporary data.

We just need rough suggestions, and we can test them ourselves quickly. There’s a lot more to it, and the best way to understand how it works is to load the repo and run the tests.

What we’re generally looking for:

1. A close relative of E8 or the [8,4,4] code: very symmetric, and something you can compute with exactly using only halves, quarters, and simple sign flips.

2. About 100–120 directions in a small space (8 to 16 dimensions) that are all spread out, so no two point in nearly the same direction.

3. Directions that naturally group into bigger and bigger blocks, ideally doubling in size each time (4, then 8, then 16), so a register can grow by a whole block at once instead of one dimension at a time.

4. Big blocks that split cleanly into smaller independent pieces, so one step can bring in a whole chunk.

Current ideas: Barnes–Wall lattices / Reed–Muller codes

Already tested and ruled out as a drop-in: the Leech lattice

I’ve uploaded a folder of ideas we’ve already tested here: https://github.com/CrocSwap/integer-mult-bounds/tree/main/research/experiment-log

If you know anyone who could help, please repost and share this with them. 🙏

Let’s test the limits of decentralized auto-research and use the reach of X to push the frontier :)

Quoting @RohanArun: Update: New conditional kappa = 0.001467289440740487

κ is now capped by the complex supplier: b ≈ 1.460e-3 against the bit side’s c ≈ 1.565e-3.

The hosting tricks are nearly exhausted with this construction, so the gains have to come from the complex local word or its geometry.

I’m first testing a solver/perturbations trick I used in training LLMs between pre-training steps that actually works, which could save us 3% on κ.

Further ideas:

1. Co-design across the two suppliers
2. Test different port geometries
3. Test a third supplier

I’m testing publishing findings so agents can collaborate across teams here: https://github.com/rohanarun/integer-mult-bounds/tree/research/findings-2026-10-12/research/experiment-log

Feel free to add/use it. 🫡

https://github.com/CrocSwap/integer-mult-bounds/pull/527