The sum-of-three-cubes problem asks which integers can be written as three integer cubes. Our target is 114, an unresolved case in the literature reviewed for this campaign:
The coordinates may be positive or negative, and enormous cubes can nearly cancel. An answer is one exactly verified integer triple. There is no known small search bound that guarantees our campaign will contain one.
Our current approach generates modular roots through cubic-field norms, rejects impossible candidates with exact arithmetic, and searches 81 explicitly bounded contexts. A shared completed-task index avoids work already known to be finished. Measured cost and a declared geometric prior adjust allocation after each 64 verified tasks, while preserving 40% uniform task proposals. It has not learned where a solution is likely to be.
This is an open computational research project by Kuber Mehta. The gamble is spare processor time for a possible mathematical discovery. We publish the algorithms, finite search definitions, unsuccessful experiments, verification records and evolving model so the work can be inspected and reproduced.
Contribute in your browser → · Run on your own computer · Read the research verdict · Read the working paper
Live leaderboard, current totals and evolving Mermaid allocation · Play on the website
Generated receipts, coverage and policy histories live on cluster-data. main holds reviewed code and research; gh-pages holds the built website. Routine Pages refreshes run every 20 minutes. Existing source-branch data is a frozen bootstrap snapshot for reproducible offline builds, not the latest campaign.
The public engine uses cubic-field norm generators to reach selected large divisors without factoring each one. With
Adjoint coefficients produce a cube root
The 81 contexts are the Cartesian product of three class multipliers
These finite generators and ratio bands do not cover every integer triple, every modular root, or a complete height box. They can overlap historical searches or the separate Mac campaign. No effective small bound guarantees that a representation lies in our chosen catalogue.
Every 64 verified tasks freezes a policy. The production method combines a declared geometric band/shell prior with measured curve yield and aggregate CPU, including empty tasks. It keeps 40% uniform task proposals; those are selection shares, not CPU budgets or discovery probabilities.
flowchart TD
Source[Reviewed source on main] --> Replay[Independently replay banked tasks]
Replay --> Ledger[Canonical receipts on cluster-data]
Ledger --> Geometry[Geometry prior plus measured curve yield and cost]
Ledger --> Shadow[Spatial challenger: frozen predictions and later errors]
Geometry --> Policy[Versioned production policy]
Shadow --> Evidence[Report evidence; no automatic promotion]
Policy --> Pages[Build gh-pages every 20 minutes]
Evidence --> Pages
Pages --> Clients[Independent local seeds and exact coverage checks]
Clients --> Replay
Policy equations and limitations · Mathematical coverage scope · Branch and deployment design
The initial discovery-learning experiment failed its promotion test. The new geometric preference is uncalibrated for our selected norm families. A stronger sieve, reduced duplicate work and better cost predictions are useful, but none establishes the likelihood of finding 114.
Browser workers use BigInt; the portable Python kernel uses arbitrary-precision integers. Each result has a fixed task descriptor and deterministic digest. GitHub ingestion independently replays every unseen task, compares the full result digest, and credits the actual issue creator once. Submitted seconds and claimed machine speed do not increase the leaderboard. Any candidate identity receives a separate exact cube check, even when its surrounding receipt is malformed. A standalone identity can also be submitted for verification without claiming any completed search tasks; it earns no invented task credit.
The shared completed-task index contains exact task IDs in SHA-256 checked, immutable hash-routed chunks. Runners v0.3.1 and newer read coverage v2; older runners need an upgrade. Clients skip IDs in their checked snapshot and local completed records. There is no probabilistic membership filter that could discard unvisited work. Simultaneous clients can still select the same unfinished task, and stale or offline snapshots cannot know about later completions; the server deduplicates accepted work.
A digest detects changed bytes, but does not prove who physically supplied CPU time. Full negative replay is the current trust model and creates a central cost. Expected analytic counts and conservation checks are useful diagnostics; they do not prove that each candidate was visited. See the protocol, cluster design, and response to the external critique.
Use the browser or the local runner to contribute. Keep your saved receipts until the published audit confirms them. The source archive, validation record, developer setup, and release evidence support independent review.
The working paper records implementation and evidence. Its result and discovery attribution remain blank pending an independently verified and reviewed identity.
The mathematical approaches are credited to Booker–Sutherland, Grantham–Walsh and the primary sources in the research verdict. This independent project is not endorsed by those authors. Original project software is GPL-2.0-or-later; upstream material retains its notices.
September audit corrections: immediate discovery recovery, bounded warmed replay, exact chunked coverage and the v0.3.1 runner.
The spatial model learns cost and arithmetic counts from verified task geometry. It remains in shadow; improved prediction error has not demonstrated better discovery odds.
