3.1 Preparing the kernel 3.2 Building the Sample Problems 3.3 Running the Sample Problems 3.3.1 Symbolic Regression 3.3.2 Artificial Ant 3.3.3 Boolean 11-Multiplexer 3.3.4 Two-boxes 3.3.5 Lawnmower 3.4 Compiling Without the Makefile
Compiling lil-gp
When you unpack the distribution, you should get this directory
tree:
lilgp/
appdocs/ (documentation)
ant/ (artificial ant problem) lawnmower/ (lawnmower problem) multiplexer/ (Boolean 11-multiplexer problem) regression/ (symbolic regression problem) skeleton/ (skeleton code for new problems) twobox/ (two-boxes problem)
kernel/ (kernel source)
params/ (sample parameter files)
aux/ (miscellany)
This chapter describes how to prepare the kernel, and how to build
and run the five sample problems included in the distribution.
It assumes your system is running on some flavor of Unix, and
has the GNU make utility available. If you don't have
GNU make, read section 3.4 for tips on writing your own makefile
or compiling manually.
First you should examine the file GNUmakefile.kernel in the kernel directory. At the top will be things (such as compiler flags) that need to be set for various systems. Look to see if you need to make any changes there.
Secondly, you need to customize the timing code, since timing relies on system calls which vary from system to system. You need to create a pair of files, event.c and event.h. There are three pairs of files provided:
ev_times Use this if your system has the times() system
call. It will provide wall clock time, in addition to processor
time spent in user and system spaces, to (on most systems) .01
second resolution.
ev_time Use this if your system only has the time()
system call. It will provide wall clock time only, to the nearest
second.
ev_none Use this if nothing else works. It provides
no timing information at all, but will work on anything.
Copy the appropriate pair to event.c and event.h.
Under Unix, that
would be something like:
% cp ev_times.c event.c % cp ev_times.h event.h
If you do not know which to use, try them in the order listed.
If compilation fails with a message like "Undefined symbol,"
then try the next one. If all else fails, ev_none will
always work since it is not system-dependent.
3.2 Building the Sample Problems
Go into the directory for the problem you want to build. Type make. If all goes well, you will be left with an executable named gp in the directory. You can type make clean to remove all the object files in that directory, leaving only the executable.
There is a makefile in the directory of each sample problem. Each of these "include"s another file, Makefile.kernel, located in the kernel directory, which compiles the kernel code. Application- specific makefile changes should be made in the problem's directory, while modifications to the kernel should be reflected in the kernel makefile, so that they will be visible for all applications
The application makefiles included assume use of the gcc
compiler. If you do not have that, you can change the makefile
to use something else. Look for the line CC = gcc and
change gcc to cc, or whatever the name of your C
compiler is. You may also need to change some of the compiler
flags found just beneath that.
3.3 Running the Sample Problems
This section describes specific features and parameters for each
sample problem.
This uses GP to "discover" the function x4 + x3+ x2 + x, given some randomly chosen sample points in the interval [-1, 1). In addition to the normal output files, it creates another (with the extension ".fn"), that has the best-of-run function evaluated at 201 points over the interval of interest. You can use this file directly in a plotting utility such as gnuplot to compare the evolved function with the objective function
There are three application-specific parameters.
app.use_ercs | type: binary | If yes, an ephemeral random constant terminal (with the range [-1; 1)) is added to the function set. | default: yes |
app.fitness_cases | type: integer | The number of fitness cases generated (sample points in the interval). | default: 20 |
When this problem computes the difference between the ideal value
of the function and the value returned by the individual, large
values are capped so as not to produce infinite results. A parameter
controls the value of this cap:
app.value_cutoff | type: double | Maximum allowed value for the difference between objective function and evolved individual for any one fitness case. Larger values are replaced by this number. | default: 1e15 |
You can change the objective function by editing app.c,
in the function app_initialize().
This problem has three parameters:
app.maxtime | type: int | Maximum number of time steps before the ant "times out." | default: 400 |
app.trail | type: filename | The name of a file depicting the "trail" of food for this run. The first line of the file should have the x and y dimensions. Remaining lines should have a "#" to indicate a square with food, any other character to indicate a blank square. | default: none |
app.use_progn4 | type: binary | Whether or not the PROGN4 fucntion should be included in the function set. | default: no |
Two trail files are provided in the ant/ directory: santafe.trl and losaltos.trl, both taken from Koza's first book
In addition to the normal information, the .bst file contains
the number of time steps used by the ant, the food collected,
and a picture of the trail. Blank squares are shown by a ".",
uneaten food is a "#", squares the ant passed
through have an "x", and the final location and
facing direction of the ant are indicated by a "N",
"S", "E", or "W"
in the appropriate square.
This problem has no parameters specific to it. The .bst
file contains the usual information plus a Koza-esque "scoreboard,"
with hits indicated by "*" and misses by ".".
3.3.4 Two-boxes
There are no application-specific parameters, and no problem-specific
output is generated.
This problem has three parameters:
app.use_adfs | type: binary | Controls whether the ADFs are used. | default: yes |
app.lawn_width | type: int | The width of the lawn. | default: 8 |
app.lawn_height | type: int | The height of the lawn. | default: 8 |
3.4 Compiling Without the Makefile
You will first need to set up the event.c and event.h files just as if you were using a makefile. Look in the file GNUmakefile.kernel in the kernel directory. The first three lines (beginning kobjects = main.o
gp.o eval.o ...) list all the kernel object files that need to be built, along with the application objects function.o and app.o. Building all those together should produce the executable.