Math Gambling

7 min read Original article ↗

An open computing experiment in the sum-of-three-cubes problem.

Stake some processor time. Chase a mathematical jackpot. The odds are absurdly long and we can’t price your hand. Most bets will return nothing. One exact answer would be a discovery.

Bet some compute

25% · Gentle

GentleBalancedAll in

Run seedAssigned when you play

Inputs checked
0

Curve intervals
0

Exact tests
0

Batches played
0

The run

— intervals / sec

No hands yet.

Loading local receipts…0:00

Banking opens a GitHub issue. Passed sampled banks earn contribution credit; exact verification is shown separately.

My bank history

Search activity

0 / 81 lanes played

Rejection sieve (log scale)

—

—

No hands yet.

Global leaderboard

— contributed inputs on the table.

Alias GitHub Contributed inputs Verified inputs
Loading contributions…

Contribution includes provisional credit from passed sampled banks; it is not certified coverage.

Loading the shared ledger.

See the whole cluster ↗

The house is still looking.

Fetching the latest Mac report.

My Mac’s contribution to the cause.

—curve intervals checked

—exact square tests

—solutions

Curve intervals checked · cumulative

Loading recorded computation history…

Search pace · intervals per second

How I ended up here.

Hi, I’m Kuber Mehta, a 19-year-old college student. While trying to solve impactful problems with LLMs, I stumbled across the sum-of-three-cubes problem and worked on an optimized search to solve 114 on my Mac. Then I looked at the compute estimates. A day of work for a chance this small? That’s math gambling, so I decided to bring everyone along for the ride.

So here we are. Bring a computer and lower your expectations. We might find something extraordinary.

Read the increasingly elaborate attempt ↗

Okay, give me an estimate.

≈ 1 in 1.7 million

per extra core-day, in an idealized reference-engine search.

A back-of-envelope benchmark, not measured odds for this browser. It assumes the published density model, fresh frontier coverage, and the speed of our reference calibration. Our selective search may differ drastically.

Show the assumptions & the maths

We use ρ = 0.0584593, a historical-region cost of ≈270 core-years, and P(t) = 1 − exp[−ρ ln(1 + t/270)], with t in core-years. One core-day gives ≈0.0000593%. Doubling that whole region gives ≈4%; a tenfold region gives ≈12.6%.

This is a conditional Poisson extrapolation. Historical coverage is not independently certified here; the finite norm sampler is not equivalent to a full frontier extension. These are guesses under stated assumptions, not a lower bound or a guarantee.

Booker–Sutherland density model · Our measured calibration and limitations

The evolving ML approach

Epoch —

Learn which batches buy more exact search per second. Keep exploring the rest.

64verified batches per update

40%predicted CPU exploration

—lanes with enough observations

Waiting for the ledger

Each bar is one search context. The dashed line is uniform allocation. Select a bar for its weight.

Loading the published policy method. Allocation is a search preference, not a discovery probability.

Inspect every context and epoch ↗ · Read the failed experiment ↗

Can task geometry teach us more?

Challenger · shadow only

Loading frozen model evaluations…

Every 1,024 verified tasks freezes a new spatial model. We test its predictions on the next window of receipts. It watches the search; the published scheduler above still makes the decisions.

No evaluation selected

━ Later submitted tasks┄ Unseen geometry

Above zero means lower prediction error. Historical backfills are retrospective tests; submitted work is not a random sample. Better predictions do not establish better chances of finding 114.

A small performance pilot

Quotient exposure per CPU, relative to the legacy scheduler tested in this pilot. Four seeds; about 8.35 CPU-seconds across all four tested arms. Exploratory, not sufficient for promotion or a multiplier on discovery odds.

Design, promotion gates and the exploratory performance pilot ↗ · Chart data ↗

Did my Mac’s model predict actual performance?

Recorded holdout: predicted versus observed throughput on logarithmic axes. Diagonal = perfect prediction. This is the native Mac model, separate from the volunteer learner above.

High rollers welcome.

Got a computer you can leave running? Download the local runner, choose your time and worker budget, and give 114 more attention than it deserves.

Working implementation draft. The answer and finder stay blank until verified.

math-gambling · working draftResult pending

A distributed, verifiable search for
x³ + y³ + z³ = 114

Draft started September 2026

Abstract

We describe an open volunteer search for integer solutions to x³ + y³ + z³ = 114. The implementation combines a cubic-field norm construction, exact arithmetic, modular rejection, bounded client tasks, durable result receipts and independent replay. Scheduling combines measured curve yield and execution cost with an explicit geometric prior while preserving exploration. The selected domains are finite and do not constitute an exhaustive height search. No solution is claimed in this draft.

1. Problem and motivation

The sums-of-three-cubes problem asks for integer triples representing a prescribed integer. The congruence obstruction modulo 9 excludes values congruent to ±4; 114 passes this necessary test. Its passing the test does not prove the existence of an integer solution. This project makes a previously local computational experiment reproducible and open to volunteer contributions.

2. Search construction

For S = x + y and V = x − y, the defining identity is

3SV² = 4(114 − z³) − S³. (1)

Writing D = |S| reduces z to roots r of r³ ≡ 114 (mod D), with z = r + Dq. To generate selected roots, let α³ = 114 and use

N(a + bα + cα²) = a³ + 114b³ + 12996c³ − 342abc. (2)

Fixed class lattices and finite coefficient domains define each task. Congruence filters precede exact square, integrality and parity checks. Every emitted triple must satisfy the original integer identity. The mathematical domain and implementation limits accompany the source.

3. Volunteer execution and verification

Opt-in browser clients use a Rust WebAssembly kernel with a BigInt fallback; the local runner offers Rust computation with exact wider final checks. Bounded deterministic task receipts are banked as GitHub issues. The authenticated issue author supplies attribution; posting establishes submission, not correctness. A scheduled verifier independently replays accepted tasks, deduplicates task identifiers and preserves exact positive identities. Display names are self-reported; leaderboard identity comes from the issue author. Eligible negative banks are randomly sampled after submission. Unreplayed claims earn no verified credit, certify no coverage and supply no learning observations.

4. Adaptive allocation

Every 64 newly verified tasks freezes a policy. Existing epochs retain their original method. The current policy combines aggregate curve yield and CPU, including empty-task costs, with an uncalibrated geometric band/shell prior. New epochs reserve forty percent of predicted CPU equally across contexts; actual device costs vary. The shared-feature predictor stays in shadow, and the earlier discovery experiment failed its acceptance test. Neither is a validated estimate of discovery probability.

5. Validation and limitations

The preceding native campaign recovered all 662 known-positive fixtures in its regression corpus and included arithmetic-boundary, differential and crash-recovery checks. Those results apply to the archived native release; the portable public client has its own independent cross-language tests. Neither set is a formal proof of the complete software stack. Public receipts only certify the finite task actually replayed. Unknown global coverage and unknown success probability remain central limitations.

6. Result (intentionally unfilled)

Verified solution (x, y, z)
________________________________________

Finder / verified contributor
________________________________________

Discovery date and receipt
________________________________________

Independent reproduction
________________________________________

No counters, near misses or local credit preview fill this section. It requires an actual independently verified identity.

7. Reproducibility and attribution

Code, fixed task definitions, verification tests, strategy revisions, research notes and their failed hypotheses are maintained at github.com/Kuberwastaken/math-gambling. Final authorship and discovery attribution require evidence and agreement; participation alone does not confer authorship.

References

  1. A. R. Booker and A. V. Sutherland. On a question of Mordell. PNAS 118 (2021). arXiv:2007.01209.
  2. J. Grantham and P. G. Walsh. Representing integers as a sum of three cubes. (2022). arXiv:2211.12149.
  3. S. G. Huisman. Newer sums of three cubes. (2016). arXiv:1604.07746.
  4. math-gambling. Implementation, campaign evidence and research verdict (2026). Versioned project repository.