Mtgp: a multithreaded java tool for genetic programming ...

MTGP: A MULTITHREADED JAVA TOOL FOR GENETIC PROGRAMMING APPLICATIONS A.M.S. Zalzala’

D.Green

Department of Computing & Electrical Engineering, Heriot- Watt University, Edinburgh, EH14 4AS, UK. Email: a.zalzala@,hw.ac.uk

Research Machines Plc, 183 Milton Park, Abingdon, Oxfordshire, OX14 4SE, UK. Email: Dgrepn(iirmdc.net

Abstract: MTGP is a new genetic programming system that uses the multithreading technonogy of the Java programming language for the parallel evolution of subpopulations of programs. The system runs as a Java applet within a standard web browser on a desktop PC, and utilises a linear program representation for a stack-based virtual machine. The individuals from four subpopulations are manipulated concurrently and these subpopulations exchange their best individuals at regular intervals during a run. MTGP incorporates novel variations on the traditional genetic operators used in genetic programming and in the inclusion of a ‘do nothing’ gene, in an attempt to produce better evolutionary performance. The basic procedures of the system will be used in the future development of a distributed, Internetbased genetic programming system that will provide large computational power needed to solve complex problems. In this report, the performance of MTGP on two symbolic regression problems is compared to that of four other genetic programming systems. MTGP shows improvement over these systems in terms of the computational effort needed to solve the problems and the accuracy of the solution produced.

1. Introduction GP is inherently a computational intensive process due to the many evaluations and manipulations of a potentially large number of programs, over a large number of training cases [l]. A way of reducing the computational load, and hence increasing the speed, is to parallelise the evolution process and use a multi-processor system to evaluate sub-populations [6]. This necessitates some form of parallel system that can be achieved by setting up a local processor network, for example using transputers [ l l ] or MIMD computers [9], or by connecting together a number of workstations [lo]. The transputer and MIMD networks, although successfd, require some specialist knowledge and are relatively expensive to set up, whereas the connection of desktop PCs or workstations is inexpensive and easy to implement. An even cheaper method is to use the existing network that forms the Internet, which can potentially have millions of computers from all over the world, all connected simultaneously. Within Universities and companies in the UK alone, there are many thousands of computers that are idle for a great deal of time, at night, for example, whose processors could be put to work. A centralised controller could assign sub-populations of individuals to these computers, via the Internet, which would carry out evaluation or evolution tasks within the JVM of each computer and then report the results to the centralised store. In this manner, huge populations of

0-7803-5536-9/99/$10.00 0 1 9 9 9 IEEE

individuals could be speedily evaluated in a massively parallel process. The major obstacle to this system at present, is the speed of data transmission and communication over the Internet medium. The rate of transmission using existing telecommunication methods is generally too slow and unreliable for an Internet-based GP system to be feasible. However, it is envisaged that in just a few years time, telecommunications technology will have advanced to the extent that a large-scale distributed GP system will be a reality. It is the primary aim of this work to provide the basis, in terms of theory and programming constructs, for the development of a Internet-based, large-scale, distributed GP system.

2. Java for Genetic Programming The choice of programming language is a simple one for this project and was assumed at the time of conception of the project. Java is the only language that supports full portability and is the recognised computer language for Internet applications [3,4]. There have been few reports of GP systems implemented in Java [IO], but considering the relative youth of both GP and Java, it is not too Surprising that Java has not been applied to GP with much frequency. The support for multithreading built in to Java ,makes it an ideal choice for use in evolving parallel populatiofis of individuals. The program will be run in the form of a Java applet that will execute within the JVM of a web browser. The JDK (Java Development Toolkit) Version 1,l is used to code the system, which will run in the Microsoft Internet Explorer 4.0 web browser on a P233 computer. The type of problems that the system will be required to solve needs to be addressed early in the design stages, as the problem-type dictates certain properties of the system. For example, some types of program representation are better at producing solutions in certain circumstances and the type and format of the training data determines the exact form that program evaluation should take. In this project, it was decided that the system should aim to tackle symbolic regression [2] types of problems. Symbolic regression is the determination of a program, in the form of a mathematical function, to relate two series of data, i.e. the input and output training data. This type of problem has been tackled by previous GP systems coded in C [9] and Java [lo] and so will provide a means of comparing the performance of the system, Using the system for symbolic regression means that the trdning data will always be in a numeric form and so a simple fitness function can be used. For the purposes of this system, a fitness function based on minimising the sum of the Square of the error (SSE) of a program will be used.

’Corresponding author. 904

3. GP System Design The choice of which of the two, major GP algorithms to use in the system is again clear as the steady-state algorithm, incorporating tournament selection, provides the only real way to parallelise the evolution process. This type of system has already been successfully implemented by Hulse et al. and a variation on the standard form of the steady-state algorithm is to be used in this work. Parallelisation is to be provided to by dividing the population into four and evaluating each of these sub-populations as if they were on different processors. The sub-populations will interchange their best individuals at regular intervals in an effort to speed up the evolution of a solution, which is the operating principle of a system known as the 'Island Model' [I 13 of GP evolution. The interchanging of individuals will coincide with the evaluation of the complete population, defined as being a steady-state generation, and so the best individuals of an adjoining sub-population can replace the worst individuals of a sub-population.

3.1. Program representation The type of program representation and the manner in which the programs will be decoded must also be decided upon at this stage. The most suitable choice for the system is to use a linear program representation with stack-based decoding as these are relatively easy to implement in Java and have been wellresearched and documented [7- lo]. Despite the general approach of the GP system being similar to that of other researchers, there are a number of novel variations to be used in this work. The first of these is to allow the individual programs to be of variable length, as opposed to the fixed length programs. This was so that the program size could evolve naturally and the eventual size of the solution to the program would be as uninfluenced as possible by the parameters of the system. The only parameter of the system pertaining to program size is the initial size of the programs in the population; evolution is then left to take its course. A further variation introduced in this work is the way in which the hoop' or hop' (no operation) gene is used in the program representation. In previous work, 19,101, this operator has simply being used to ensure that the linear program string is always of the same length, however as the programs used in this research are of variable length, any such operator is effectively redundant. The 'do nothing' operator was instead used to simulate the effect of 'junk DNA' in biological crossover, which protects the genes from harm during crossover and recombination. It was hoped that, despite making the average program longer in length, the 'do nothing' operator would protect useful program segments as they were formed and actually speed up evolution. To aid the manually decoding of programs, the exact nature of the operation of the stack-based system was also simplified. Instead of pushing the result of the application of a function operation back onto the stack, the system will use a variable to record the results of these operations as the individual is decoded. In this way, the final value of the variable will be the output of the individual for the particular input. This will minimise the use of the stack during decoding, which is expected to increase the speed of the decoding process. In addition, as only the terminal values are to be placed on the stack, the manual decoding of the final program string into a recognisable mathematical form is made a much simpler process. As a starting point for coding, a

hnction set was chosen that represented the four basic arithmetic operators; addition, subtraction, multiplication and division, and the function set was chosen to contain only a single variable, x. This enables the testing of the system on some simple problems.

3.2. Population initialisation The system will initialise a population containing a given number of individual programs, each of the same length, and then proceed to split the population into four sub-populations of equal size. Each of the programs should consist of a random combination of genes from the terminal and fbnction sets, along with the no operation gene. The system will select with an equal probability whether a gene in a program is the no operation gene or a member of the terminal or function sets. If the latter is selected, the system should then choose, with equal probability, one gene from either of the gene sets. 3.3. T h e genetic operators The exact nature of the reproduction, crossover and mutation operators can be adjusted, depending upon the tournament size used for selection and the results of preliminary testing of the system. As a starting point, a tournament size of five individuals was chosen, as this has proved successful in previous GP systems. The exact nature of the genetic operators used in these previous systems is not described in the literature and so a new scheme for these operators was devised. This scheme involves dividing the actions of the genetic operators into two parts - a combination of reproduction and crossover, and a combination of reproduction and mutation. With the combined crossover-reproduction operation, based on a tournament size of five, the two fittest individuals from the tournament are to be selected as parents and standard two point crossover carried out between each parent to produce two offspring individuals. These offspring are then copied back into the population along with two copies of the fittest parent and a single copy of the remaining parent program. The combined mutation-reproduction operator also selects the two fittest individuals from the tournament and reproduces the fittest of these twice and other individual once, making five individuals in all. A copy of either the fittest individual or second fittest individual is chosen at random and has a single gene mutated into any other gene type. This mutated program along with the other four programs is then to be copied back into the general sub-population. The scheme was developed to use combinations of the three genetic operations to minimise the amount of code by reducing the three separate functions of reproduction, crossover By combining the and mutation into two operations. operations, it is hoped that the occurrence of premature convergence during evolution will be reduced. Premature convergence arises in a population when the variations in characteristics of a population become greatly reduced during a run, to such an extent that it is no longer possible to evolve a solution. This lack of variation occurs especially frequently with the reproduction operator as it introduces multiple versions of the same program into the population and lowers the variation. By combining the operators, it is envisaged that the usehl aspect of the reproduction operator is retained, in that healthy programs are passed back into the population still unharmed, but variability is ensured by also creating new programs. 905

out ten loops of the tournament selection algorithm and again evaluates all of the population. After this stage, the thread proceeds to create a new objeat of the RUN UPDATE class, which informs the user of the progress of the run, and passes on its two fittest individuals to the neighbouring sub-population. Each sub-population also receives the fittest individuals fiom another sub-population and uses these to replace its weaker individuals. This process is achieved by way of the queue classes, which handle the message passing, and then recreates the thread with the new sub-population, and hence the selection and evaluation process is continued. If a solution is found at any time during the decoding of any program, the SOLUTION FOUND class is referenced from the thread, which reports the solution to the user, and the GP run ends. If the maximum number of generations is reached then the GP run again finishes with a declaration to the END OF RUN class. There are a total of thirteen classes that form the applet program and the functions of each of these are indicated in brief below: 1 . Set up - applet and GP run (including population initialisation). 2. Thread 1 - handles the evaluation and selection procedures of sub-population 1. 3. Thread 2 - handles the evaluation and selection procedures of sub-population 2. 4. Thread 3 - handles the evaluation and selection procedures of sub-population 3. 5. Thread 4 - handles the evaluation and selection procedures of sub-population 4. 6. Queue 1 - passes individuals between subpopulations 4 and 1. 7. Queue 2 - passes individuals between subpopulations 1 and 2. 8. Queue 3 - passes individuals between subpopulations 2 and 3. 9. Queue 4 - passes individuals between subpopulations 3 and 4. 10. Running Frame - informs user of the progress in evolution made by each sub-population. 1 1 . Solution Frame - informs user of the solution when found by the system. 12. No Solution Found F r m e - informs the user when the GP run has reached the maximum number of generations, and a solution has not been found. 13. Error Frame - inform$ user of errors in user input.

3.4. User Interface It is the intention of the system to be as user-friendly as possible and allow the user to define some of the parameters of a GP run, such as individual size, population size, maximum number of generations to be run, minimum allowable error for the solution and the training data to be used. A single set-up screen should be used to allow the user to input the appropriate data and then start the run. It is important that the user be informed of the progress of the run, for example by reporting the best individual found in every generation, and the results of the run. If a solution cannot be found then the best individual found should be reported and upon finding a solution, the system should inform the user of the solution program, what generation it was found in and the time taken from the start of the run.

4. MTGB Implementation In the development of the MTGP system, a sequential version of the applet program was initially produced to test the procedures and operation followed by coding of the multithreaded version of the system. The overall algorithm for the basic GP part of both the sequential and multithreaded programs is that of the steady-state algorithm shown in Figure 1. Firstly, the decision whether or not to evaluate the entire population is based on the number of selection procedures that has run since the last evaluation (set to 10). The termination criteria used was that an individual gave an overall sumsquared error (SSE) of less than a value defined by the user, or the maximum number of generations to be run had been reached. The combined genetic operations and exchange of individuals upon full sub-population evaluation should also be noted as variations from the standard steadv-state algorithm. Population initialisation and division of population into sub-populations

Choose subpopulation sub-set

Copy sub-set back into sub-population

1

4.1. Applet a n d G P Run Set U p This class is the first that executes as the HTML page is downloaded into the web browser. The class is referenced by the apple tag contained in the HTML code and imports t i e packages containing the Java class libraries for the abstract window toolbox (awt), utilities and applet packages. This allows the class to use the standard methods contained in these libraries and all of the classes in the program draw on these methods. The class also inherits fiom the general applet class and implements the ActiobListener interface to enable the applet to respond to user commands. The next step of the class is to declare the objects a f the classes that are needed to call the methods of other classes or are later shared by instances of other classes. The appearance of this layout is shown in Figure 2.

END OF RUN

Figure 1: The GP system steady-state algorithm The algorithm is implemented across a number of separate classes that combine to produce the full GP system. If the user inputs the parameters for the run in the correct format, four different threads are then spawned that handle the evolution of the four sub-populations. If an error is found in the input data, the GP run fails to begin and an object of an error class is executed to inform the user. At the start of each run, each thread firstly evaluates the whole of its sub-population and declares an object of the RUN UPDATE class, which reports the results fiom each thread to the user. The thread then carries

906

Upon the user entering the set up data and pressing the mouse button, the program calls the actionPerformed method of the class and proceeds to convert the data from the text strings input by the user and initiate the population. The population is initialised by means of the pseudo-random number generator of the Random class, from the utilities class library. Two loops, one within the other, are used to produce totalpop individuals in a previously created array called population. The inner loop produces each individual program of length indSize which consists of a random assortment of genes consisting ofthe terminal set {x}, function set {t, -, /, * } and the operator n which does nothing. The n operator is selected with a 50% probability and each of the remaining genes with a 10% probability to ensure that on average, there are more n genes than any other single gene in a program. The inner loop algorithm uses random numbers to decide which gene should be copied to the program until the program is of the desired length. Methods of the StringBuffer class are used to copy each individual gene to the program string, which is assigned the temporary name s. After creating the entire population, the class divides this population into four subaouulations bv using four seDarate loops.

-