Extending an expert's tables for unsolved take-away games in a way he could check himself

In a take-away game, two players take turns removing counters from heaps, and the player who cannot move loses. Each game is named by a short code such as 0.007. 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.007 you may only ever take three counters, with all three options allowed (7 = 1 + 2 + 4). Mathematicians call these octal games because no digit is more than 7. 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.

Richard Guy conjectured decades ago that in every game of this kind the list of nim 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 this: by a theorem of Guy and Smith from 1956, once the values have repeated for long enough (a little more than twice the point where the cycle starts, plus one cycle), they repeat forever, and many games have been solved that way. What no table can show is that a game never repeats. None of the games here has started repeating yet, so people compute further and watch what the values do.

The values to watch are the rare values. Flammenkamp sorts each game's values into two classes, rare and common: 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. His page notes that if a game's rare values stop for good, its values must eventually repeat. So the main question for each longer table is whether new rare values turned up past the old limit. The page on game 0.007 works through the test with an example and gives the reason.

The largest run, for 0.007, took its table from about 268 million heap sizes to about 1.07 billion. In eight of the games, no new rare values appeared anywhere in the extended range, which fits with those games eventually repeating but does not prove it. Four games did turn up new heap sizes with rare values: 185,576 of them in 0.114, 8,162^▲ in 0.606, 2,932 in 0.006, and exactly 1 in 0.314. In those four the rare values had not stopped by the end of the new tables, so if the values ever settle, it happens further out. In 0.606 the new rare values are packed into a narrow band, which I can't explain and have asked Flammenkamp about. Every game, with its old and new limits and the details for these four, is in the table on the results page for this work.

Before any run computed new values, it had to reproduce the published tables exactly, not approximately. The published tables list several statistics at their limit, and every one of them had to match before a run could continue. Two further steps made it safe to leave the long runs unattended: the runs saved their progress with checksums, and before launch I confirmed that a run that is stopped and resumed gives bit-identical output. At the end, separately written code (also written by a Claude agent) recomputed the published starting values byte for byte and found every new rare position again, so that no new number depended on a single program. The full list of checks, in the order they ran, is on the results page for this work. The same approach fits any project that extends someone else's published computation.

These are octal games from Guy's list of unsolved problems; the open question for each is Guy's conjecture that its nim-sequence (its sequence of Sprague-Grundy values) is ultimately periodic. Periodicity, when it holds, is provable by finite computation (Guy and Smith, 1956: G(n + p) = G(n) for n0 ≤ n ≤ 2n0 + p + k − 1, with k the number of code digits); no table can establish aperiodicity. Rare values are Flammenkamp's sparse-space class, and if they die out the sequence is ultimately periodic. Eight of the games show no new rare values anywhere in their extensions. The remaining four differ from each other: one has many new rare positions with small values, one has new rare positions with values in a tight high band, one has them scattered over a wide range, and one has a single new rare position far out. I have no explanation for the tight band and have asked Flammenkamp. Every run first reproduced every published invariant at the prior bound, including the zero counts, and only then extended. Afterwards, separately written code recomputed the published prefixes byte for byte and found every new rare position again. The per-game counts and value ranges, stated as new rare positions whose values lie in a range, are on the results page for this work.