Attributes marked with * must be defined in Algorithm::_init() for each new application/experiment.
This is the name of the file which contains the training data and is eventually passed to loadSet().
This is the name of the file which contains the testing data and is eventually passed to loadSet().
May take the values `up' or `down' depending how your fitness measure works. Set it to `up' if a big number means good fitness, and `down' otherwise.
This is set automatically in TournamentGP::_init() if you don't provide a value for it. See Section 3.1.2.
Each Algorithm object has a Population object, and this is where it is stored.
This variable contains the current tournament number. In the case of restarted runs, it is initialised to the value in the last line of `results/tournament.log' (see Table 1), otherwise it defaults to 1. It is incremented in run().
This is the number of tournaments that run() tries to run, regardless of the initial value of Tournament (in the case of a restart).
This is a counter, like Tournament which is incremented every tournament, however this is reset to zero when a new best-of-run (fitness better than BestFitness) Individual is found.
This variable holds the fitness of the best-of-run Individual and is used for checking to see when a new best-of-run Individual is found. On restarts it is reinitialised from `results/tournament.log'. The term ``best-of-run'' may not always mean exactly that; if for example the refresh() routine is used to dynamically change the training data.
The number of Individuals chosen for each tournament.
The number of parents given the chance to reproduce during a tournament. It's a good idea if this is an even number, and is less than or equal to half of TournamentSize.
Individuals in a tournament which have taken part in TournamentKillAge or more tournaments are not sorted on fitness, but are automatically placed at the bottom of the list. This ensures constant turnover and is the opposite of elitism. If you find that your population is never ``getting off the ground'', consider raising this to 4 or maybe more. You can think of TournamentKillAge as the number of attempts allowed for each Individual to produce viable offspring.
When true, forces re-evaluation of fitnesses every tournament (and does not take the value from memory to save time).
When true, the second parent (the first is always taken from the top of the fitness-sorted list of Individuals) is taken from a random position in the list, but this position is biased towards the top.
The name of the main log file.
How often TournamentLogFile, FitnessesFile and some other log files are written.
The log file where the sorted fitnesses of the Individuals in the last tournament are saved. The file does not contain the fitnesses of the Individuals older than TournamentKillAge.
The log file where population complexity information is saved.
How often ComplexityLogFile is written.
If non-zero, how often the refresh() method is called.
The file where the training data output from the recent best-of-tournament Individual is written (using the saveOutput() method).
The file where the testing data output from the recent best-of-tournament Individual is written (using the saveOutput() method).
The file where the Perl code of the recent best-of-tournament Individual is written.
The file where the training data output from the best-of-run Individual is written (using the saveOutput() method).
The file where the testing data output from the best-of-run Individual is written (using the saveOutput() method).
The file where the Perl code of the best-of-run Individual is written.
If non-zero, all the best-of-run Individuals are saved in KeepBestDir.
The directory in which the complete history of best-of-run Individuals may be saved.
If non-zero, the maximum number of best-of-run Individuals saved in KeepBestDir. Older Individuals are removed when the limit is reached (to save disk space).
If non-zero, how often is a tar.gz file of the complete population saved to the directory PERLGP_POPS.
If non-zero, how often Population::emigrate() is called on Population.
If non-zero, how often Population::immigrate() is called on Population.
If non-zero, the number of seconds that the system alarm() call is set for, before calling evaluateOutput(). This is a one-size-fits-all alarm time. If you want the alarm time to be proportional to the amount of training data you have, you can put alarm calls directly inside the loop (over data-points) in the evolved evaluateOutput() method. For example, in the sine demo in Section 9.2 you could put an alarm(1) just before ``begin evolved bit'' comment and an alarm(0) just after the ``end evolved bit'' comment.
When non-zero, forks the main process before calling evaluateOutput(). This can prevent nasty crashes with ``panic: leave scope inconsistency'' messages when you are using non-zero AlarmTime or other alarm() calls. Don't use it unless you get these errors.