El proceso de concesión a favor de Bear Creek

The failure of early trials without Automatically Dened Functions (ADFs) and Koza's strong advocacy of them Koza, 1994, page 646] lead to the decision to implement ADFs within the GP-QUICK frame work (cf. Section E.2).

The initial implementation was very much like that used by Koza but contained no restrictions upon the primitives that could be used within the ADF tree. I.e. each primitive could occur in each of the operations and the ADF. In Koza's ADFs the function and terminal set are usually dierent from those in the main tree (in his terminology, \the result producing branch"). Typically his ADFs do not have primitives that enable them to access the actual variables of the problem, instead access is indirect via the ADFs' arguments Koza, 1994, page 75].

Subsequently the implementation was extended to allow each tree to have unique terminal and function sets. NB each operation (\result producing branch") can also have a unique set of primitives (Section 4.9).

In later experiments described in this chapter the ADF concept was extended in three ways:

1. The ve operations may themselves be treated as evolving functions and be called by other operations. When they nish processing instead of causing the program to halt, control returns to the caller, which continues execution.

This new ability was introduced because sometimes the requirements of one opera- tion can be a subset on another's. For example front's functionality is a subset of that required of dequeue (cf. Table 4.1) and so in later experiments (Sections 4.9 and 4.10) dequeue is allowed to treat front as an ADF. Whilst this would seem intu- itively reasonable, in principle it means more analysis must be performed before the problem is given to the GP. An alternative could be to use an ADF which the two operations could share. This would be more general in that it allows the operations to have common functionality, rather than one being a subset of the other but this would require the co-evolution of three program trees rather than two.

2. As the name implies, automatically dened functions are normally viewed as com- puting a function of their inputs which they return to their caller. However their purpose in GP is to ease the evolution of functionality, especially where it is repeat- edly required. If the ADF is restricted to returning its answer but the functionality requires some variable to be updated, then code to transfer the ADF's answer to the

variable must be used whenever the ADF is called.

For example if, as part of a bigger program, we wish to evolve code that increments one of a number of variables. We would expect a parameterised ADF to be helpful. The ADF can simply increment its argument and then the ADF can be called with each variable as its argument. But if the ADF can only read its arguments, it must return the value of the variable plus one and rely on code at each point where it was called to update the correct variable with the new value.

It is expected that generally it will be harder to evolve such multiple instance of code (which may deal with dierent variables and could be in dierent trees, and thus cannot share genetic material at crossover, Section 2.3.5) than if a single instance of code to update the ADF's argument, which automatically ensures the correct variable is modied, could be evolved once within the ADF.

In traditional programming languages, this is done by passing the variable to the function by reference so the function can manipulate the variable directly. When the function is called a check is often made that the function's argument is indeed a variable and a reference for it exists. Whilst it would be possible to build such a check into GP crossover (and other genetic operators), thus ensuring only legal programs are generated, this means making a distinction between variables and constants. In normal GP there is no such distinction, all genetic material has the same type. Whilst such distinctions can be made, as discussed in Section 3.3.1, this is a eld of research in its own right and would have been too much of a distraction from this thesis. Therefore the genome interpreter was made suciently robust to cope with arbitrary code as the argument of ADFs that use pass-by-reference. Should more than one variable occur in the the ADF's argument, the reference of the last is used. If there are only constants, the ADF does not try and update them.

Instead of introducing primitives to explicitly update ADF arguments, it was decided that such ADFs should implicitly update their argument by setting it to the nal value calculated by the ADF as it returns to its caller. The ADF also returns the calculated value. Whilst this is straightforward and reduces the volume of code in the ADF it means it is impossible for an ADF with more than one argument to update them independently. For our purposes this was not necessary and the implementation only allows an ADF's rst argument to be passed by reference. Section 4.10.4 describes one case where this feature was used.

3. Syntactic and semantic restrictions on the ADF were also introduced. These are described in Section 4.10.3.

There has been only a limited amount of work on allowing recursion within genetic programming Koza, 1992, page 473], Brave, 1996c], Sharman and Esparcia-Alcazar, 1993], Whigham and McKay, 1995, page 19], Nordin and Banzhaf, 1995a] and Wong and Leung, 1996]. Recursion and GP is a big and important research topic which would be too much of a distraction from this thesis. Therefore, whilst recursive calls are implemented, recursion is not allowed in any of the experiments in this thesis. In Sections 4.7 and 4.8 recursion is prevented by a run time check which aborts tness testing (in the same way as memory address errors in Section 3.3.1). In all other experiments the syntax of the evolving programs is designed to prevent recursion occurring.