Evolutionary Computation : A Unified Approach

5.5. EA-BASED AUTOMATED PROGRAMMING 109
• ML-EAs can be used effectively for other kinds of ML problems, particularly “sequential
decision problems” like navigation and game playing that involve a coordinated
series of decisions extending over time (Smith, 1983; Grefenstette et al., 1990).
• Most ML problems of interest involve significant amounts of computation time. Hence,
ML approaches that lend themselves to parallel implementations are desirable.
5.5 EA-Based Automated Programming
The dream of automating the frequently tedious job of computer programming has been
with us since the early days of computer science and artificial intelligence. It should come as
no surprise that this was also on the minds of the early pioneers of evolutionary computation.
As noted in chapter 2, in the early 1960s Fogel and his colleagues were motivated by the goal
of producing intelligent artificial agents, not by hand-crafting them, but by evolving them.
As a starting point they chose to use finite-state machines (FSMs) as their programming
language and called their techniques for evolving FSMs “Evolutionary Programming” (Fogel
et al., 1966).
Similarly, we find in Holland’s early writing a description of his “broadcast language”,
a parallel programming language designed to facilitate manipulation by GAs and modeled
loosely on gene-level mechanisms of protein production (Holland, 1975).
Since then there has been considerable interest in evolving programs expressed in a wide
variety of languages, including rule-based systems (Smith, 1983; De Jong, 1987), artificial
neural networks (Harp et al., 1989; de Garis, 1990), Lisp code (Fujiki and Dickinson, 1987;
Koza, 1992), and even assembly language (Cramer, 1985; Ray, 1994). In each case the
ability to do so effectively depends critically on two important issues: 1) how a PROG-
EA represents and manipulates programs, and 2) how to assess the fitness of a candidate
program. These issues are explored in more detail in the following sections.
5.5.1 Representing Programs
The simplest and most straightforward approach to representing programs is in terms of a
fixed set of parameters. That is, we have a particular class of programs in mind that vary
only with respect to their parameter settings, and we want to find the particular program
instance whose execution behavior is optimal with respect to some objective criteria (such
as execution speed, correctness of the output, etc.). The advantage to such an approach is
that it immediately places us on the familiar terrain of parameter optimization, and we can
use a variety of the techniques discussed earlier in this chapter to evolve programs.
It is tempting at first glance to dismiss this approach as trivial and not at all representative
of what is usually meant by automatic programming. But it is important to note that,
although the kinds of structural changes that can be made is quite limited, even modest
changes in parameters can result in significant behavioral changes during program execution.
Samuel’s checker-playing program (Samuel, 1959) is a striking example of this. And,
one can view the unified EA model developed in the previous chapter as a parameterized
description of a class of algorithms that exhibit a wide range of behaviors.