Turn three integers into a constrained search.
Set S = x + y and V = x − y. The equation becomes:
Choose D = |S|. A necessary condition is z³ ≡ 114 (mod D), so z lies in arithmetic progressions z = r + Dq. We search those progressions, then ask whether the expression for V² is a nonnegative integer square. Parity gives integer x and y. Finally, we check the original cube identity exactly.
This transformation is the reason we don’t simply try every possible triple. It does not remove the difficulty of finding a useful progression.
Build roots with a cubic number field.
Let α³ = 114. For integer coefficients a, b, c, use the norm
Our fixed families use ℓ ∈ {1, 5, 25} and D = N/ℓ. Put B = 114c² − ab and C = b² − ac. When C is invertible modulo D, r = B/C mod D provides a modular cube root, which we check explicitly. The coefficient regions are defined using exact integer formulas.
The public worker samples small blocks from the same 81-context family as the Mac’s optimized search. Large D begins just beyond 10¹⁹/54; this is a selective frontier search, not a complete survey of every root there.
Read the domain argument →Let proofs reject. Let models schedule.
Divisibility, congruences, parity and quadratic-residue tests remove impossible candidates before arbitrary-precision square tests. A model never decides that an untested candidate cannot work.
First, check the exact norm and whether it belongs to the task’s allowed shell.
Our existing native release measured about 1.58× the earlier version on a paired workload benchmark. Another proposed sieve cut exact tests by a third but gave no overall speedup, so we rejected it. Optimization is an experiment, not an adjective.
Share work. Learn the cost. Repeat.
Clients choose tasks from a versioned strategy. Completed results stay in a durable local outbox. Bank up to 256 tasks by pasting a compact receipt into a GitHub issue. The issue author supplies authenticated submission attribution. Posting an issue does not certify its mathematics.
GitHub Actions reacts to new or edited bank issues and replays a bounded queue using an independent Python implementation. Exact positive identities are preserved. Matching negative results count as verified coverage, with duplicate task IDs counted once. Every 64 newly verified unique tasks is a calibration epoch.
At least 40% of allocation remains exploration. Cost estimates use verifier measurements, rather than trusting client speed claims. This measures useful arithmetic per unit compute under a stated weighting model. It is not a learned probability of finding 114. A separate held-out discovery-learning experiment failed its acceptance test.
There is a cost to strong verification: replaying every negative task repeats the work. This first version prioritizes verifiable results and may bottleneck at the verifier. It has not demonstrated linear speedup from more volunteers. Future cheaper audit schemes would need weaker, explicit coverage claims.
Inspect the current allocation and evidence →The 81 search lanes, explicitly
Each lane fixes one class lattice, coefficient shape, divisor shell and quotient band. A task selects at most 128 coefficient rows and 16 offsets in that lane. Different task IDs identify different coefficient blocks; unit-related generators can still reach the same mathematical root.
D₀ = ⌊10¹⁹ / 54⌋ = 185,185,185,185,185,185. The three shells are (D₀, 2D₀], (2D₀, 4D₀], and (4D₀, 8D₀]. The ratio bands are 0 < |z|/D ≤ 64, 64 < |z|/D ≤ 256, and 256 < |z|/D ≤ 4096.
These are selected norm families above a historical divisor frontier, not a proof of complete coverage there. Starting below 2⁵⁸ does not itself imply repeating the historical rectangular search: 2⁵⁸ is larger than D₀.
All lanes and their exact bounds
| Lane | ℓ | Shape | D minimum (exclusive) | D maximum | |z| / D |
|---|
Published completed-task index · Full arithmetic scope and exclusions
What this cannot promise
- A solution exists for 114: not proved by this project or the literature we reviewed.
- A finite budget is enough: no proven containing bound, no reliable discovery ETA.
- The globally best algorithm: our benchmarks compare specific implementations and workloads.
- All values are covered: finite selected coefficient blocks and quotient bands leave other regions untouched.
- No repeated effort in all circumstances: clients skip tasks in the latest published coverage index, but simultaneous or stale clients can still overlap. Verified task receipts are deduplicated; Mac and volunteer coverage are not added into a single “unique” total.
- Perfect software: exact arithmetic, independent verification and extensive tests provide evidence, not a formal proof of the complete stack.
Booker–Sutherland’s density heuristics help explain why the problem is hard. They do not give calibrated odds for our selected norm families. We therefore display no win percentage, countdown to discovery, or misleading “percent complete.”
Run it locally
Install Python 3.11 or later. Download and unzip the portable runner, then run:
cd math-gambling
python3 tools/runner.py --name "Your name" \
--github username --minutes 60 --workers 1
Your processor and time limits are explicit. Use --help for
offline mode, receipt output and optional automatic submission with the
GitHub CLI. Stop with Ctrl+C; completed work is saved. Names are
self-reported; the leaderboard credits the authenticated GitHub account
that submits the issue.
The native C/PARI research implementation is separate from this portable client. It offers substantially different performance and has its own ledger and build instructions. We don’t pretend the Python download is a native-speed port.
Your device & data
Nothing computes until you choose Let It Ride. The browser uses one Web Worker, defaults to a gentle duty cycle and pauses when hidden. There is no browser time limit. You can stop immediately; only finished tasks are credited. Processor work uses electricity and can warm your device.
When you choose to bank your work, submissions contain your chosen alias, optional GitHub handle, task parameters, exact counters, digests and any candidate identities. Attribution and accepted mathematical results can appear publicly in this repository and site. Your browser stores your profile and pending receipts locally. No email, wallet, advertising tracker or browser GitHub token is needed.
GitHub may process ordinary network metadata. The leaderboard uses the actual issue author, not the optional handle entered in this form. A posted issue means “awaiting verification.” Offline work stays “saved locally,” never “verified.” Use an alias if you don’t want a real name published.
Standing on other people’s mathematics
Start with Booker & Sutherland, On a question of Mordell, Grantham & Walsh, Representing integers as a sum of three cubes, and Huisman’s computational results. The notebook covers lattice methods, geometry, elliptic curves, heuristic search, failed optimizations and our validation evidence. This is an independent project, not an endorsement by those authors.