Extending the table for one unsolved take-away game to four times its published length

The game is played with heaps of counters. On each turn a player takes exactly three counters from one heap. The player may take a whole heap of three, leave the rest of the heap as one heap, or split the rest into two heaps (each with at least one counter). The player who cannot move loses. Played on a strip of squares, the same game is Treblecross: players take turns putting an X in an empty square, and the first to complete three in a row wins.

The name 0.007 is a code for these rules, and every game in this family has one. 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, and so on. 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. Here the first two digits are 0, so you may never take one or two counters, and the third is 7 = 1 + 2 + 4, so taking three is allowed with all three options. No digit can be more than 7, which is why these are called octal games.

Every heap size has a nim value, worked out from the smaller heaps up. List the values of all the positions one move can reach from that heap; the nim value is the smallest whole number (0, 1, 2, and so on) missing from the list. This rule is called mex, short for minimum excluded value. The value of a position made of several heaps is the nim sum of the heaps' values: add them in binary without carrying. A position is lost for the player to move exactly when its value is 0. So a table of nim values, heap size by heap size, is a complete guide to playing the game, as far as the table goes.

Richard Guy conjectured that in every game of this kind the list of values eventually repeats in a cycle. If it does, the game is solved, because a finite table then gives the value of every heap size. A finite table can prove that a game repeats: Guy and Smith showed in 1956 that a long enough stretch of repeating values guarantees the repetition goes on forever. How long is long enough depends on the number of digits in the game's code. Suppose the values repeat with a cycle of length p, starting from heap size n. For 0.007, which has three digits, if that repetition has been checked up to heap size 2n + p + 2, the values repeat forever. What no table can show is the opposite, that a game never repeats. For 0.007 no repeating cycle has turned up yet.

Achim Flammenkamp, who keeps the reference tables for these games, sorts each game's values into two classes, rare and common, with a test on their binary digits. Each game has its own test. For 0.007 it works like this. Write the value in binary and look only at the places worth 8, 16, 32, 128, 256 and every higher place; ignore the places worth 1, 2, 4 and 64. If an even number of the places you looked at hold a 1, the value is rare. If an odd number do, it is common. For example, the last rare value in the table, at heap size 5,029,983^▲, is 530, which is 512 + 16 + 2. The places looked at that hold a 1 are 512 and 16: two of them, an even number, so 530 is rare. (A ▲ after a number links to a note about it at the bottom of the page.) The largest value in my table, 1,689, is 1024 + 512 + 128 + 16 + 8 + 1, and five of the places looked at hold a 1, so it is common.

Flammenkamp's page notes that if the rare values stop for good, the values must eventually repeat. The reason, which follows the remark on his page, comes in three steps. First, the test fits nim addition: combining a rare value with a common one gives a common value, and combining two values of the same class gives a rare one. Second, once the rare values have stopped, every new value is common, so each new value is just the smallest common number that no move reaches; moves that reach a rare value make no difference. By the first step, a position of two heaps has a common value only when one of the two heaps has a rare value. So the only moves that matter are moves that leave a single heap, or two heaps of which one has a rare value. A heap with a rare value is then one of the finitely many heap sizes that have one, so the other heap is always within a fixed distance of the current heap size. Third, each new value then depends only on a fixed-length stretch of the values just before it, and his page also shows the values stay below a fixed bound. A sequence like that can be in only finitely many states, so it has to cycle. That is why the thing to watch in a longer table is whether new rare values turn up.

A Claude agent working under my direction wrote the program, under a rule I set: no new value counted until the run had reproduced everything the old table recorded. That meant the largest value and where it sits; how many heap sizes have value 0 and where the last one is; the same two numbers for the rare values; and, for each value that is a power of two (1, 2, 4, 8 and so on), the first heap size that has it. All of it matched.

The last rare value is still the one at heap size 5,029,983, far inside the old table. None appeared anywhere from about 268 million to about 1.07 billion, and the largest value stayed at 1,689. That is evidence that the rare values may have stopped for good, which would make the game eventually repeat. It is not a proof, because a rare value could still appear further out.

Flammenkamp reviewed the code and reran the old table's range with his own program, getting the same numbers. He then took the game to about 2.1 billion heap sizes (2^31). His run found the same count of rare values and the same largest value, which also covers my range, though he and I compared those summary numbers rather than every value. His table now goes to 2^34, about 17 billion heap sizes (checked 2026-10-29). It still lists no rare value after heap size 5,029,983, and its largest value is now 1,691, a common value two above the old largest. The furthest values for this game are his. The other games from the same July work are on the results page for that work.

0.007 is Treblecross. The computation is a checkpointed sparse-space computation in the style of the reference tables, written by a Claude agent working under my direction. It computed every value from heap size 0 to 2^30^▲, which includes the prior bound of 2^28 (a ▲ marks a figure with a note at the bottom of the page). It was required to reproduce the published invariants at the prior bound, and it was cross-checked against a naive quadratic enumerator on the first 100,000 heap sizes. Past the prior bound there is no rare value beyond the last known one, and the maximum is unchanged.

Rare values are the sparse-space class in Flammenkamp's sense: G(n) is rare when popcount(G(n) AND m) is even, where m is the game's bitstring; for 0.007, m has bits 3, 4, 5 and every bit from 7 up (his page writes it lowest bit first). The parity of popcount(x AND m) is additive under XOR, so once the rare values die out (last rare index L), G(n) is common and is the least common value not attained by the options, and the only options with common values are the single-heap option G(n − 3) and the pairs G(a) ⊕ G(b) with a + b = n − 3 and G(a) rare (so a ≤ L). The mex computation then becomes a shift register of length about L + 3 over values bounded as on his page, so the sequence is ultimately periodic. No period has been detected, so the octal periodicity test (Guy and Smith, 1956: G(n + p) = G(n) for n0 ≤ n ≤ 2n0 + p + 2 implies ultimate periodicity for a three-digit code) does not yet apply.

The published artifacts are the full table as a binary file with a recorded checksum, the list of rare-value pairs as the compact citable table, the run log, and a one-line reproduce command. Flammenkamp reviewed the solver source, reproduced the 2^28 range with his own program, and later extended this game on his own hardware: to 2^31 with the rare count and the maximum unchanged, and by late October to 2^34 on his page, with the rare count still unchanged and the maximum at 1691 (up from 1689).