Offspring 1 Offspring 1
3.1.3 Iteration
3.1.3.1 Iteration Primitives
In the system implemented by Koza [KOZA92] the function set contains the iteration primitive DU (do until). DU takes two arguments, a body to be executed on each iteration, and a condition. The iteration stops when the condition specified as the second argument of the DU is met. A maximum number of 25 iterations can be performed by each DU instance and a maximum of a 100 iterations per individual is permitted.
A similar primitive, namely forwhile, is used in the GP system developed by Langdon [LANG98b]
to automatically induce methods for the list abstract data type. Nestedforwhile loops were not allowed, and only 32 iterations per forwhile was permitted.
In the GP system proposed by Pringle [PRIN95] iteration is catered for by the WHILE primitive.
Like the DU operator the WHILE takes two arguments, a body to be executed on each iteration and a condition. However, in this case the iteration is terminated when the condition specified is no longer satisfied.
3.1.3.2 Automatically Defined Iterations and Loops
This section describes how iterative structures can be incorporated into the architecture of individuals. Automatically Defined Iterations(ADIs) and Automatically Defined Loops (ADLs) are used for this purpose. An iteration forms the basis of both ADIs and ADLs. An iteration, as defined by Koza [KOZA99], consists of essentially four components:
• An initialization.
• A termination or continuation condition.
• The body of the iteration.
• An increment or decrement step.
ADLs and ADIs are described below.
3.1.3.2.1 Automatically Defined Loops
According to Koza [KOZA99] automatically defined loops are used to implement a general iteration in a genetic programming system. ADLs are comprised of four branches, namely a loop initialization branch (LIB), a loop condition branch (LCB), a loop body branch (LBB) and a loop update branch (LUB). An invocation of the loop results in the LIB branch being evaluated followed by the LCB branch. Depending on the result of the evaluation of the LCB branch the LBB will be executed followed by an evaluation of the LUB branch or the loop will be terminated.
An ADL is assigned a name and an argument list. Koza [KOZA99] suggests that an indexing variable is needed to keep track of the number of executions performed in an iteration.
ADLs can be incorporated into a genetic programming system by using architecture-altering operations or creating individuals during initial population generation that include ADL structures in their architecture. Architecture-altering operations are discussed in more detail in section 3.4.
3.1.3.2.2 Automatically Defined Iterations
A special instance of the general iteration structure is problem-specific iteration, i.e. iteration needed to access the elements of an array, a finite sequence or a vector. The initialization step, the continuation/termination condition and the increment or decrement step is fixed in this case.
Automatically-defined iterations are used to represent these problem-specific implementations of an iteration while automatically-defined loops are used to represent the general iteration structure.
The structure of an ADI consists of a name, argument list and body. The body of an ADI is executed more than once, i.e. for each element of the array, vector or finite list. ADIs can be incorporated into the GP system by creating individuals specific to the ADI architecture, i.e with a results-producing branch (representing the main program) with zero or more ADI branches, during the process of generating the initial population. Alternatively, architecture-altering operations can be used for this purpose. Architecture-altering operations are discussed in section 3.4.
3.1.4 Recursion
Recursion has not been used as widely in GP systems as iteration. Like iteration, recursion can be incorporated into a GP system by adding a recursion operator to the function set or including an automatically-defined recursion component in the architecture of each individual.
In a study conducted by Koza [KOZA92] to automatically induce the Fibonacci sequence using genetic programming, the SRF primitive was used to cater for recursion. SRF takes two integer arguments, K and D. As each element of the Fibonacci sequence was generated this value was stored and used by SRF to calculate successive elements of the sequence. If the K -th element of the sequence has already been computed SRF returns the value of this element otherwise it returns D.
Brave [BRA V96] has implemented a GP system to evolve a recursive algorithm that performs a binary tree search. The system developed by Brave [BRA V96] uses automatically defined functions (defined in section 3.2.1) that are allowed to call themselves to perform recursion. An automatically defined function can be called recursively until the maximum depth of the tree being searched is reached. Further recursive calls result in the value of the leaf node at the current position being returned. This system proved to be more successful at evolving the binary search algorithm than the standard GP system and the standard GP system with non-recursive ADFs.
A structure more recently used to incorporate recursion into a GP system is Automatically Defined Recursion (ADR). ADRs consists of four components, namely, a recursion condition branch (RCB), a recursion body branch (RBB), a recursion update branch (RUB) and a recursion ground branch (RGB). ADRs can be incorporated into the population by specifying an architecture inclusive of ADRs for the generation of the initial population or by using architecture-altering operators. Figure 3.3.1.4.1 illustrates an example of an individual using an ADR. Architecture- altering operations are discussed in section 3.4.
1
Figure 3.3.1.4.1: ADR Example
An invocation of an ADR results in the RCB being firstly executed. If the evaluation reveals that the condition represented by the branch holds, the RBB branch is then evaluated followed by the execution of the RUB. When the recursion terminates the RGB is implemented. Thus, if the specified condition is met the result of the RBB is returned while if the specified condition is not met the result of the RGB is returned. The RBB branch of the ADR may contain a call to itself.
A unique name and an argument list is assigned to each ADR branch. Invocations of an ADR may be in a results-producing branch (representing the main program), or an ADF 12 , ADI, or ADL branch.
3.2 Modularization
According to Banzhaf et al. [BANZ98] and Langdon [LANG98b] modularization is a technique commonly used by human programmers in problem-solving. In order for the genetic programming algorithm to induce efficient solutions and deal with larger programming problems, it is essential that modularization is catered for [BANZ98]. A number of attempts have been made to extend the standard genetic programming system proposed by Koza [KOZA92] to include modularization.
These include automatically defined functions, encapsulation, and module acquisition. This section examines each of these methods.
3.2.1 Automatically Defined Functions (ADFs)
Koza [KOZA94] introduces the concept of subroutines within a program by means of automatically defined functions. According to Langdon [LANG98b] the incorporation of ADFs in GP systems has enabled genetic programming to solve problems previously unsolved by the standard GP system. Automatically defined functions enable a genetic programming system to solve a problem by decomposing it into subproblems. The GP system implemented by Koza [KOZA94]
simultaneously induces a main program together with the subroutines called by the main program.
Genetic programming does not generate programs in the same way as a human programmer writes programs. Thus, the automatically defined functions induced may not be defined in the same way as those created by a human programmer.
ADFs are not beneficial for simple problems. The use of automatically defined functions decreases the computational effort needed to find a solution as well as increases the parsimony of solutions provided that the problem is of sufficient difficulty [KOZA98b]. The benefits of using ADFs increases with the complexity of the problem.
Koza [KOZA94] has found that a GP system incorporating the use of ADFs has the lens effect, i.e.
it tends to find individuals that have extreme fitness scores.
Sections 3.2.1.1 through to 3.2.1.5 examines the implementation details of using ADFs.
3.2.1.1 Representation of each Individual
Each individual of the population is represented as a tree containing one or more function-defining branches, representing each ADF, and a results-producing branch, representing the main program.
The results-producing branch can call the functions defined by the function-defining branches.
12The concept of an ADF is presented in Section 3.2.1.
The evolutionary process determines how many times and in what manner each of the functions defined by the function-producing branches are called.
Koza [KOZA94] presents the following example tree consisting of one function-defining branch and one results-producing branch. This tree represents a program in Lisp.
progn
6 values
4 5
8
Figure 3.3.2.1.1.1: ADF Program Structure
Koza [KOZA94] describes the first six points in this tree as invariant and the remaining two as non-invariant. Each node is defined as follows:
1. The first node in the tree is the root of the tree. In this case the Lisp connective progn is the root of the tree and combines together the statements representing the automatically defined function and the main program.
2. The Lisp primitive defun which marks the beginning of each function in Lisp.
3. The name of the automatically defined function. 4. The argument list of the automatically defined function.
5. Returns value/s outputted by the automatically defined function. 6. Returns value/s outputted by the results-producing branch, 7. The body of the automatically defined function.
8. The body of the results-producing branch.
If the rninimalist approach is taken each individual in the initial population consists of a single function-defining branch which takes a single argument [KOZA98b].
If more than one value is returned by the results-producing branch, a number of sub-branches exists under the values node in the results-producing branch. The actual variables of the problem are defined by the results-producing branch and can be passed to the function defining branches. The different scenarios for function calls between ADFs are discussed in section 3.2.1.2. Koza [KOZA94] presents the Lisp program in Figure 3.3.2.1.1.2 as an example.
Bruce [BRUC95] suggests that instead of using a single tree to represent the main program and the ADFs the genotype can consist of n trees stored in a fixed-size array, one representing the main program and the n-l trees representing the n-l ADFs. The user has to specify the number of abstract trees in each genotype. The user must also specify how the evaluation of each tree will contribute to calculating the overall fitness of the individual.
4 1
7
ARG1
5
8
o
Figure 3.3.2.1.1.2: Lisp program with ADFs presented by Koza [KOZA94]
Bruce [BRUC95]states that this representation has a number of advantages over the representation used by Koza. Firstly, it simplifies the representation of programs including ADFs. As we are now dealing with separate trees and not a single tree with constraints on which branches are modifiable, the genetic operators do not need to be adapted. This representation is more general, e.g. the genetic programming system without the use of ADFs is essentially this system with the size of the genotype being one. Figure 3.3.2.1.1.3 illustrates the equivalent representation for the program depicted in Figure 3.3.2.1.1.2.
ADFO Main program
Figure 3.3.2.1.1.3: Alternative ADF Representation
In the system implemented by Koza [KOZA94] a call to an ADF is treated as an element of the function set, i.e. the tree representing the ADF is applied to the arguments passed to the ADF.
Langdon [LANG98b] further extends the ADF concept by catering for pass-by-reference modules.
An automatically defined function is able to change the argument passed to it, in the same way that variables are passed by reference in a program. The ADF is not allowed to return a constant or return an output value that is equal to its input value.
The use of call-by-reference ADFs eliminate the need to update a memory location with the value calculated by the ADF.
Another alternative described by Grant [GRANOO] and Naemura et al. [NAEM98] involves maintaining two breeding pools, one to evolve ADFs and the other to evolve main programs. ADFs which result in the main programs having a good fitness are added to a library. Both pools can access the library. The system implemented by Naemura et al. [NAEM98] consists of three components, one for module generation, one for storing modules, and one for main trees.
The module generation component has its own primitive set. Subtrees contained in ADFs which appear to improve the fitness of individuals are added to the module storage component. All the programs in the main tree generation component can access this library. Modules are removed from the library if they appear to reduce the fitness of individuals and are replaced with newly found modules. A module hierarchy is developed over a run. The first layer of the hierarchy (layer-O) consists of modules composed only of elements of the GP primitive set. Individuals can access the modules in layer-O. Modules in layer-l ofthe hierarchy are composed of primitives and the modules in layer-O. Individuals can now access modules in layer-O and layer-I. This method was found to produce more parsimonious solutions.
3.2.1.2 ADF References
In programming a function can usually call other functions that have been defined. If there is more than one function-defining branch, these branches can have one of the following relationships:
•
•
•
There are no references between the function-defining branches.
References among function-defining branches are not restricted. In this case an ADF can call itself recursively either directly or indirectly. The name of the ADF is added to its function set.
A function may hierarchically call those functions that have been defined before it, e.g. in Figure 3.3.2.1.2.1 ADFO can call ADFI but not vice versa.
3 ADFO
Figure 3.3.2.1.2.1: Program with two ADFS
3.2.1.3 Changes that Need to be Made to the Standard GP System
When incorporating the use of ADFs into a GP system the user has to specify the number of function-defining branches and the number of arguments that each ADF will take. Koza [KOZA94] suggests that the number of variables of the problem should be used as an upper limit of the number of arguments that an ADF can take. If each individual will contain more than one ADF the user will have to choose one of the methods in section 3.2.1.2 to define legal calls between functions.
For each of the function-defining branches and the results-producing branch a terminal and a function set must be specified. Experiments conducted by Koza [KOZA94] have indicated that the effect of using different architectures with ADFs, e.g. individuals with four ADFs with two arguments each instead of individuals with three ADFs with four arguments each, etc, does not have a significant effect on system performance.
The method used to randomly generate the initial population must be edited to create individuals that are composed of a results-producing branch and one or more function-defining branches. The crossover operator needs to be adapted in order to ensure that crossover is performed on like branches, i.e. structure-preserving crossover must be applied to individuals so that the offspring produced are syntactically correct.
The invariant components of each individual are not altered during crossover, i.e. structure- preserving crossover is restricted to the non-invariant points of the individual. Each non-invariant point is assigned a type. Structure-preserving crossover is implemented as follows:
•
•
A non-invariant point in the first parent is randomly chosen .
A point in the second parent is randomly chosen from the points of the same type as the point chosen in the first parent.
To ensure that genetic operators are applied to the same branches in each individual, types have to be assigned to the nodes in each individual. Typing is discussed in section 3.2.1.4. Crossover occurring in the function-defining branches indirectly affects the main program whilst the opposite is not true.
One of the disadvantages of using ADFs is that parameters, e.g. the number of ADFs and the number of arguments of each ADF needs to be preset prior to evolution [NAEM98].
3.2.1.4 Typing
The following methods can be used to assign types to the non-invariant nodes:
•
•
Branch typing - According to Koza [KOZA94] there is one type for each branch. A different type is assigned to the non-invariant points of each branch. In the tree in Figure 3.3.2.1.1.2, the function-defining branch is of type seven while the results-reproducing branch is of type eight.
Point typing - Each individual non-variant point in the overall individual is assigned a type. Each type has a function set, a terminal set, an argument map, and a description of the syntactic constraints of the branch where the node is located, associated with it.
Koza [KOZA94] suggests that point typing be used in systems where the overall program architecture is evolved during the run (see section 3.2.1.5 ).
• Like-branch typing - Points in branches that have the same terminal and function sets are assigned the same type [KOZA98b].
According to Koza [KOZA99] branch typing is the most commonly used typing method. In GP systems which automatically evolve the architecture of the individuals together with evolution of a solution, it is essential that point typing is used.
3.2.1.5 The Automatic Evolution of the ADF Architecture
One of the methods described by Koza [KOZA94] which can be used to determine how many ADFs each individual should have, the number of arguments of each ADF, and the terminal and function set of each function-defining branch is prospective analysis of the nature of the problem.
The method of prospecti ve analysis in vol ves using our knowledge of the problem domain to choose the number of ADFs and the number of arguments for each ADP. The amount of prospective analysis that needs to be done is dependant on the user's goals. Alternatively, the method of using affordable capacity can be employed for this purpose. In this case the computer resources available dictate the architecture of the system. A third alternative is the evolution of the ADF architecture. Instead of the user specifying the number of ADFs, the number of arguments each ADF should take, and the nature of hierarchical references between ADFs, these architectural characteristics can be developed together with the solution to the problem.
The function set of the results-producing branch consists of the primitives of the problem as well as the n automatically defined functions, where n and the ADFs will be generated by the GP system. The function set of each function-defining branch will consist of primitive functions as well as the ADFs that the particular ADF can access hierarchically, i.e. all the ADFs defined before it. The terminal set of the results-producing branch will consist of the variables of the problem.
These can be passed to the ADFs but are not contained in the terminal sets of the ADFs. The terminal set of each function-defining branch contains n dummy variables. For each ADF the number of arguments for the ADF is randomly chosen from a specified range.
The architecture of each offspring will be inherited from the offspring's parent/parents. An automatically defined function appearing in more than one parent can possibly have a different number of arguments in each of the parents although it will have the same name. Structure preserving crossover together with point typing is used to ensure that both syntactically and semantically correct offspring are produced.
Automatically Defined Functions (ADFs) can be incorporated into the architecture of each individual during the process of initial population generation, i.e. each program in the population is composed of one results-producing branch and zero or more function-defining branches.
Changes have to be a made to the process used to generate the initial population randomly. The number of ADFs that an individual contains is randomly chosen from a specified range, e.g. 1 to 3. A number of arguments, within a specified limit, for each ADF is randomly chosen. Zero is included in the limit range. The ADFs are systematically named, ADFO, ADFl, etc. According to Koza [KOZA94] the maximum number of arguments permissible in an ADF can be made equal to the number of variables for the problem. In some problems having an ADF with
°
argumentsmay be meaningless and hence the range of arguments must begin at one.