Extending the tables for a set of unsolved take-away games, checked and built on by the expert who keeps them
In July I pushed the published tables for a set of unsolved take-away games two to four times further. In four of the games, new heap sizes with rare values turned up.
Each run first reproduced the old table exactly. The expert who keeps the tables reran one game over its old range and others over their full new ranges, with his own programs, and got the same numbers, credited the work, and has since extended every game himself.
- Plain version: For anyone: no notation, everyday words
- Applied version: For practitioners: how it was done, what it took, and what carries over to other work
- Technical version: For specialists: full notation, definitions, and the earlier best results
Switching versions changes only the wording. Numbers, dates, sources and caveats are the same in every version.
What was done
In July I computed new values for ▲ unsolved take-away games, going two to four times past the end of their published tables. Those tables are kept by Achim Flammenkamp, and the one for the largest game, 0.007, had stood since 2021. Every run first had to reproduce his published numbers exactly, so when I sent him the work he could check it against his own and build on it. He reran 0.007 over his old range with his own program, and reran two other games, 0.006 and 0.606, over their full new ranges with his own programs, all with the same numbers. He credits the work by name on his page, and has since extended every one of the games further himself. What this work leaves behind is the checked tables, ▲ sequences in the OEIS (the online database of integer sequences), and his new runs on the same games.
An AI agent wrote the code that computed the tables, under a rule I set: no run could report a new number until it had reproduced the old table exactly. I ran it on one laptop, decided what to send, and wrote to Flammenkamp.
In a take-away game, two players take turns removing counters from heaps. Each game's rules say how many counters a player may take and whether a heap may be split in two, and the player who cannot move loses. Mathematicians call this family octal games and name each game by a short code, such as 0.114. Every heap size has a number called its nim value, which tells you how to play that heap. A value of 0, for example, means the player whose turn it is will lose against perfect play. A table of nim values, heap size by heap size, is a guide to playing the game.
For many of these games nobody knows whether the list of nim values eventually repeats in a cycle. That is what "unsolved" means here. If the list does repeat, the game is solved: a finite table then gives the value of every heap size, however large. The question has been open for decades and is on Richard Guy's list of unsolved problems in combinatorial games. Since nobody can prove it either way, people compute the values as far as they can and look at what they do.
The values to watch are the rare values. Flammenkamp sorts each game's values into two classes with a fixed test on their binary digits. Values in one class turn up only rarely, and his page calls them rare values. His page also notes that if a game's rare values stop appearing, its values must eventually repeat, which would settle the game. So the main question each new table answers is whether rare values keep turning up past the old limit.
The largest run, for game 0.007, took its table from about 268 million heap sizes to about 1.07 billion. In 8 of the games, no new rare values appeared anywhere in the extended range. That fits with those games eventually repeating, though it does not prove it. In the other four, new heap sizes with rare values did appear, so in those games the rare values have not stopped, at least as far as the new tables go:
- Game 0.114, taken from about 67 million heap sizes to about 268 million: there are new heap sizes with rare values. Their values lie between 160 and 1,021, lower than in any of the other three games below.
- Game 0.606, from about 268 million to about 537 million: there are ▲, with values packed into a narrow band, from 1,026 to 1,069. Nobody has an explanation for the band yet, and I have sent the question to Flammenkamp.
- Game 0.006, from about 67 million to about 134 million: there are , with values spread from 1,537 to 4,605.
- Game 0.314, from about 67 million to about 134 million: there is exactly , at a heap size of about 131 million, and its value is 1,936. The game's previous rare value was at about 40 million. A rare value that far out shows that a long stretch without any does not prove they have stopped.
Each run passed four checks, in this order, before any new number was used. First, a simple brute-force program had to give the same first values. Second, at the old table's limit, the run had to reproduce that table exactly: the number of rare values, the position of the last one, the largest value, and the number of heap sizes with value zero. Third, long runs saved checkpoints, and before each long run started I confirmed that stopping and resuming gives identical output. Fourth, after the run, separately written code found every new rare position again from scratch.
These are octal games from Guy's list of unsolved problems in combinatorial games. For each game, the rare (sparse-space) positions past the prior bound, stated as new rare positions whose values lie in a range: 0.114 has , with small values; 0.606 has ▲, with values in a tight high band; 0.006 has , with values scattered widely; 0.314 has , far past the prior bound. Every other game extended here has no new rare positions, which is consistent with eventual periodicity of its nim-sequence but does not prove it; by Flammenkamp's remark, periodicity follows if the rare values die out. There is no explanation yet for the tight band in 0.606, and the question has been sent to Flammenkamp. Each extension first reproduced every published invariant at the prior bound, including the zero counts, and a from-scratch recomputation afterward gave byte-identical output.
How the tables' maintainer checked the work
I sent Flammenkamp the reproduction first, showing that every number he had published matched exactly, and only then the new range. He reviewed the code. For 0.007 he reproduced my run over his old range and then took the game further, to about 2.1 billion heap sizes, with the same rare values and the same largest value. He reran 0.006 and 0.606 with his own programs, and both matched mine exactly over the whole new range. His run of 0.114 later gave the same count for every value as mine. His page credits the extended data by name, and he has since extended every one of the games past where I stopped, so the furthest values for these games are now his.
Notes on the numbers marked ▲
- Unsolved take-away games whose published tables I extended in July 2026: Achim Flammenkamp, who keeps the reference tables, has since taken every one of these games further on his page (as last checked on 2026-10-25), so the furthest values for them are now there, not here.
- OEIS sequences from the July 2026 take-away game tables: There are eleven sequences for twelve games because one game did not get an OEIS entry of its own.
- heap sizes in game 0.606 with rare values, newly found between the old table limit (about 268 million heap sizes) and the new one (about 537 million); their values lie in the narrow band 1,026 to 1,069: I have no explanation for why these values fall in such a narrow band, and I have asked Achim Flammenkamp about it.
These notes appear in every version of this page.
How this was checked
Reproduced known values first
Every run reproduced the old table at its limit (how many rare values, where the last one is, the largest value, how many zeros) before it was allowed to go further.
Jul 17, 2026
Confirmed by an outside expert
Achim Flammenkamp reran the largest game over his old table's range, and two other games over their full new ranges, on his own machines with his own programs, and got the same results. His reference page credits the extended data, and the sequences were accepted into the OEIS after its editors reviewed them.
Jul 22, 2026
Revision history
- 2026-10-22 · revised
Said exactly what the tables' maintainer reran: the largest game over his old range, two other games over their full new ranges, and a fourth game matching later.
How to cite this
Tyler Satchel Orden (2026). Extending the tables for a set of unsolved take-away games, checked and built on by the expert who keeps them. Cyborg Mathematics. https://cyborgmathematics.com/results/octal-fleet-records (updated October 22, 2026)
This page has no DOI of its own. Cite the URL and the date; the revision history above keeps a dated citation meaningful.
BibTeX
@misc{orden2026octalfleetrecords,
author = {Tyler Satchel Orden},
title = {Extending the tables for a set of unsolved take-away games, checked and built on by the expert who keeps them},
year = {2026},
howpublished = {Cyborg Mathematics},
url = {https://cyborgmathematics.com/results/octal-fleet-records}
}See also
- A dropped digit sat in an OEIS entry for years until a Claude agent spotted it. What that means for anyone who copies values from reference tables.What a long-standing error in a math database means for anyone who copies reference values
- Checking an Erdős conjecture on every tree up to a size rules out small counterexamples but does not prove it. What such a check shows and how it is made.Why checking a math conjecture on every case up to a size is not a proof
- A network puzzle: pick as few points as possible so that every point is picked or linked to a picked one. A search I ran with Claude found a smaller set than any published.A new best-known dominating set for the twelfth Fibonacci cube, and a month-long solver run that returned no answer
- An Erdős conjecture: in every tree, the number of ways to pick k dots with no two joined rises, then falls, as k grows. I checked every tree three sizes past the old limit; it held.Checking an Erdős conjecture on every tree, three sizes further than before