What we really want is a function that will take an octal code as input, and will produce its misere game values to a particular heap size.
We want to simplify the game values wherever possible by using all the theory in Winning Ways Chapter 13, Allemang's works, and ONAG.
We want to see output that looks like
heap 1 :0
heap 2 :1
heap 3 :4
heap 4 {:4, :1}
heap 5 :2
...etc...
or something similar. The forms that are printed out should be fully reduced representations. At the minimum we want adders and nim heaps to be recognized wherever they appear.
How the simplification process is best translated into Mathematica is the problem we face.
Ideally, we would like the simplification process to work off of simpler declarative rules rather than via long and complicated procedures. We want to leverage the native pattern matching capabilities of Mathematica to their fullest.
Notes started 7 Jan 2002.
We use an explicit function MisereGame[...] to represent games.
The arguments of a MisereGame are just the options of the game.
We want to be able to 'teach' Mathematica about particular game representations and how to manipulate them
1) That a nim heap *k is MisereGame[*0,.....*(k-1)], and that we want that represented as n[k]
2) That an adder a[k]= :(2n+2) has the definition MisereGame[:(2n),:(2n+1)], and that :(2n+3) = MisereGame[:(2n),:(2n+1),:(2n+2)]
3) That a game with only nim heaps as options can be reduced to a nim heap under certain circumstances by the misere mex rule.
4) That two games can be added using the Conway summation rule.
5) That general games can be simplified by reversible move searches, provided we respect the proviso.
6) That a general game has a genus, and a definition of how to compute it.
7) That an octal code gives rise to a recursively defined sequence of game values.
8) That the order of elements inside a MisereGame[] expression is not relevant to the value.
9) That we prefer symbolic and fully simplified representations of games wherever possible over extensive representations
10) That we know how shortcut addition rules for certain games (e.g. adders & nimheaps when one summand is 0 or 1)
Maybe we can codify this by starting from the top down. Ie we start with the octal code. It defines a sequence of positions.
Each element in the sequence of positions looks like a MisereGame[...], where the typical entry inside the parenthesis is typically a sum of other MisereGame[]s.
We need notation for "known" games, For example, we use n[i] as a symbol for a nim heap. And we could use a[i] as a symbol for an adder.
We want our code to seamlessly interact with such "built-in" definitions and MisereGame[]s.
For example, we want a sum of adders to resolve to the appropriate adder, even if one of the terms is a MisereGame[] representation of an adder in tree form.
We want Mathematica to look at each heap size in turn, and calculate the simplest form of the game using the rules and all of the simplication rules described above.
How exactly should this problem be presented to Mathematica? And how should we present the results?
When an adder a[i] needs to be added to something that is not an adder, we know that their sum is not an adder. In order to find a representation of the sum, we need to get our hands on the "definition" of the adder. How is this going to work?
From the octal code, we construct a representation
misereval[code,heapsize] = MisereGame[gameval[code, heap]+gameval[code,heap], ....similar terms]
With that representation in hand to a particular heap size, start at heap size 0 and start to apply all the magic we know.
The heap of size 0 will look like
misereval[code,0] = MisereGame[]. It should simplify to n[0], ideally. How are we going to cause that to happen?
In this way of looking at things, we're rewriting gameval expressions to MisereGames, and then to named special games such as n[i] or a[i].
The first step in simplification is replacement of the previously obtained misereval[] values inside the outer MisereGame expression by the results of earlier simplifications. At the very least we know a MisereGame representation of each such misereval[], and we may even know a named game representation.
The second step is to attack the inner summations....