Page 64 - 49A Field Guide to Genetic Programming

50 6 Modular, Grammatical and Developmental Tree-based GP

from ADF i can only be swapped with a subtree from another individual’s
ADF i .
The program’s result-producing branch and its ADFs typically have dif-
ferent function and terminal sets. For example, the terminal set for ADFs
usually include arguments, such as arg0, arg1. Typically the user must
decide in advance the primitive sets, the number of ADFs and any call re-
strictions to prevent recursion. However, these choices can be evolved using
the architecture-altering operations described in Section 6.1.2.
Koza also proposed other types of automatically evolved program com-
ponents (Koza, Andre, Bennet, and Keane, 1999). Automatically defined
iterations (ADIs), automatically defined loops (ADLs) and automatically
defined recursions (ADRs) provide means to reuse code. Automatically de-
fined stores (ADSs) provide means to reuse the result of executing code.

6.1.2 Program Architecture and Architecture-Altering
Operations
Koza (1994) defined the architecture of a program to be the total number of
trees, the type of each tree (e.g., RPB, ADF, ADI, ADL, ADR, or ADS), the
number of arguments (if any) possessed by each tree, and, finally, if there is
more than one tree, the nature of the hierarchical references (if any) allowed
among the trees (e.g., whether ADF1 can call ADF2).
There are three ways to determine the architecture of the computer pro-
grams that will be evolved:

1. The user may specify in advance the architecture of the overall pro-
gram, i.e., perform an architecture-defining preparatory step in addi-
tion to the five steps itemised in Chapter 3.

2. A run of genetic programming may employ the evolutionary design
of the architecture (as described in (Koza, 1994)), thereby enabling
the architecture of the overall program to emerge from a competitive
process during the run.

3. The run may employ a set of architecture-altering operations (Koza,
1994, 1995; Koza, Bennett, Andre, and Keane, 1999) which can cre-
ate new ADFs, remove ADFs, and increase or decrease the number
of inputs an ADF has. Note that many architecture changes (such
as those defined in (Koza, 1994)) are designed not to initially change
the semantics of the program and, so, the altered program often has
exactly the same fitness as its parent. Nevertheless, the new arrange-
ment of ADFs may make it easier for subsequent changes to evolve
better programs later.