Skip to content

See how this result was checked, in the evidence ledger (the site’s list of checked claims) →

RecordPublished

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.

July 16, 2026· updated Nov 6, 2026
  • 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. In four of the games, rare values (the values these tables are watched for, explained below) turned up at new heap sizes past the old limits. 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 four of the games with his own programs: 0.007 over his old range, two other games, 0.006 and 0.606, over their full new ranges, and later 0.114, 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; one is a new entry, for 0.007, and the other eleven extend entries that were already there), and his new runs on the same games. A ▲ after a number links to a note about it at the bottom of the page.

A Claude agent working under my direction 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, and the player who cannot move loses. Mathematicians call this family octal games, and each game's rules are written as a short code such as 0.114. Read the digits after the point one at a time: the first is about taking one counter, the second about taking two, the third about taking three. Each digit is a sum of up to three options, where 1 means the move may take a whole heap (leaving nothing), 2 means it may leave the rest as one heap, and 4 means it may leave the rest split into two heaps. In 0.114, for example, you may take one or two counters only when that empties the heap, and you may take three only if you split what is left into two heaps. A digit before the point is about taking no counters at all: the 4 in 4.327 means you may also just split a heap in two. No digit is more than 7, hence "octal".

Every heap size has a number called its nim value: the smallest whole number that is not the value of any position you can move to. A value of 0 means the player whose turn it is will lose against perfect play, and the values of several heaps combine by a known rule to tell you the winning move. So 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, rare and common, with a test on their binary digits. Each game has its own list of binary places to look at, and a value is rare when an even number of those places hold a 1. In practice rare values turn up at only a small share of heap sizes, and his page notes that if a game's rare values stop for good, its values must eventually repeat, which would settle the game. The page on game 0.007 works through the test with an example and gives the reason. So the main question each new table answers is whether rare values keep turning up past the old limit.

Here are the twelve games, with where their tables ended before July and where I took them. The limits are powers of two: 2^26 is about 67 million heap sizes, 2^27 about 134 million, 2^28 about 268 million, 2^29 about 537 million and 2^30 about 1.07 billion.

GameOld limitNew limitHow many new heap sizes have a rare value
0.0042^262^27none
0.0062^262^27
0.0072^282^30none
0.1142^262^28
0.1432^282^29none
0.1462^292^30none
0.2062^292^30none
0.2442^272^28none
0.3142^262^27
0.6062^282^29▲
4.0042^282^30none
4.3272^282^30none

In eight 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 had not stopped by the end of the new tables:

  • In game 0.114, the values at the new rare heap sizes lie between 160 and 1,021, lower than in any of the other three games.
  • In game 0.606, they are packed into a narrow band, from 1,026 to 1,069. I can't explain the band yet, and I have sent the question to Flammenkamp.
  • In game 0.006, they are spread from 1,537 to 4,605.
  • Game 0.314 has exactly one, at a heap size of about 131 million, with value 1,936. The game's previous rare value was at about 40 million. This one case is a warning for the eight quiet games: a long stretch with no rare value does not show that they have stopped.

Each run passed four checks. The first three came 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 (the lost positions, which Flammenkamp's tables also record). 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 (also written by a Claude agent) 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. I have 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. Afterwards, separately written code (also written by a Claude agent) recomputed the published prefixes byte for byte and found every new rare position again.

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 solver code for 0.007. For that game 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; his table now lists it to about 17 billion. 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 matched mine on how many heap sizes have each value, for every value. 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: 12. Achim Flammenkamp, who keeps the reference tables, has since taken every one of these games further, so his page (checked October 29, 2026) now has the furthest values.
  • OEIS sequences from the July 2026 take-away game tables: 12. One new entry (0.007, A395248) and eleven older entries extended; several of the older entries are filed under a related game code whose list is the same values shifted by a few places.
  • 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: 8,162. 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 three other games over their full new ranges, on his own machines with his own programs, and got the same results: four of the games in all. 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

  1. 2026-11-06 · corrected

    The check box said the tables' maintainer reran the largest game and two others; the page body already said four games, and the box now says so too, counting the later rerun.

  2. 2026-11-05 · revised

    Added a row under the title linking to the credit on Achim Flammenkamp's octal games page, which dates my work on his tables to July.

  3. 2026-10-29 · corrected

    The page gave the end of the expert's later run on the largest game as his furthest point; his table now goes much further, and the page says so. It also said a from-scratch recomputation gave byte-identical output; it now says what was recomputed: the published starting values, byte for byte, and every new rare position.

  4. 2026-10-29 · corrected

    The page said one game has no OEIS entry of its own. Every game has one: a new entry for the largest game and older entries, extended, for the rest. The count of entries is corrected to match.

  5. 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 November 6, 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