With these many preliminaries in place, we are now in a position to evolve our economy. We start with some arbitrary initial economy represented using the automatonPattern discussed above. Recall that this automatonPattern contains, in addition to some global data, a List of sites treated as a ring, each of which contain a list of programs and data on its behavior. At the outset, the behavior need not be consistent with the program or the automaton as a whole.

Starting with this initial economy, we repeatedly apply a function called process to the economy. Using Mathematica's built-in NestWhile or NestWhileList construct, this application continues for either some specified number of iterations or until some terminal condition applies. Because the process function lies at the heart of this project, we offer some detail on its operation, which exemplifies a Mathematica "functional" programming style. [Note11]

One can imagine the ring of sites as being an array of expressions e[i,j] where the i subscript denotes the position of the site in the ring (the landscape) and the j position denotes in a particular way the number of the expression at that site. In this model, e[3,1] thus denotes the first expression of the third site. We order the expressions at a site so that the first expression is the deepest in the recursive string of "how to modify". That is, it is the one that tells the site how (if at all) to modify how to modify how to modify how to modify its behavior. The second expression is the one that tells the site how (if at all) to modify how to modify how to modify its behavior. The last expression at a site is the one in which the site expresses its behavior. The second to last expression at a site is the one in which the site sets forth how to determine how to behave.

In an economy with five sites and in which we permit four layers of recursion and one program for determining behavior, the structure of the economy is as follows. [Note12]

We can then partition this array (called abstractarray) into a array (called partitionedabstractarray) of blocks such that each block contains two "adjoining" programs for each of three adjoining sites. More generally, if the original automaton has a ring with sites, each of which has expressions in it, the dimensions of the resulting partitioned array is .

A typical block might look like the following.

For each of the blocks, we now create rules. Some of these rules may be "position independent", that is, constant for all blocks depending only on the value of the entire automaton. Other rules may be "position dependent" and depend on the content of the block involved or the position of the block within the partitioned array. We then select a particular expression within the block--the one lying in the second row and first column--to transform to a fixed point using these rules via Mathematica's ReplaceRepeated construct. We then make that fixed point of the transformation an argument to a function combo that takes the entire untransformed block as its second argument. Thus, through partitioning of the original array of programs and the combo function, the programs transform themselves. The second column of programs in each block becomes data to the transformed version of the program in the second row and first column of each block. [Note13]

This functional method is used over the entire partitioned set of expressions using the MapIndexed construct that permits each block to be aware of its position in the partitioned landscape. This methodology permits each program to evolve according to its neighborhood of "surrounding" programs. The following Code Fragment 15 shows the Mathematica code needed to accomplish this complex procedure and the structure of the end product of this method. [Note14]

Zooming in, we find that the third site's new second expression is as follows.

And the fourth site's fifth expression is the following.

We generalize this portion of the process for use on any automaton by defining a function update as follows. [Note15]

The last column in this array that results from the output of update is of particular interest since it represents the new intended behaviors of each site. Using these intended behaviors, we can determine actual levels of production (after cow trampling is taken into account). From actual levels of production, we can determine equilibrium prices, and from equilibrium prices, we can determine each site's immediate and cumulative profitability.

Finally, there is the possibility of exogenous mutations by dropping sites with too low levels of profitability or cumulative profitability and replacing them by sites with randomly chosen characteristics. The function killandreplace shown below in Code Fragment 17 implements that procedure. [Note16]

We thus end up with an evolved automaton and begin the process all over again.

The code for process thus looks as follows.

Evolution is then modeled as the repeated application of some variant of a process function for the earlier of a finite number of iterations or until the application yields an expression not matching an automatonPattern. Code Fragment 20 shows how Mathematica can do this in a way that spits out just the end result of this process. Code Fragment 21 shows how Mathematica can do this in a way that spits out all iterations of this process. And Code Fragment 22 shows how Mathematica can do this in a way that spits out every nth iteration of this process in which the user designates n.