The Watchmaker Framework for Evolutionary Computation has reached version 0.7.0. If you’re new here, Watchmaker is a Java library for implementing evolutionary/genetic algorithms. This release is the most substantial update for some time.
Firstly, I’ve refactored the evolution engine so that it is not as tightly tied to the standard generational model of evolution. What this means in practice is that the class formerly known as
ConcurrentEvolutionEngine is now called
GenerationalEvolutionEngine. For most users this should be the only backwards-incompatibility in this release. The constructor arguments are the same and all the old methods are still there so it should just be a case of updating your code to use the new name. If you were using
SequentialEvolutionEngine, and I think this mostly affects the Mahout guys, this class no longer exists. Concurrency is no longer managed via different sub-classes. Instead you should also use
GenerationalEvolutionEngine and call the new
setSingleThreaded method to force all work to be done synchronously on the request thread.
If you use Watchmaker to evolve
BitString objects, this release improves the performance of the provided mutation and cross-over operators. One side-effect of this is that the semantics of the
BitStringMutation class have been modified, so you may need to adjust your parameters.
OK, on to the good stuff. The reason for the evolution engine changes was to make it easier for the framework to support different types of evolutionary algorithm. The benefits of these changes will become more apparent in subsequent releases but there is one example in this release. The framework now has first-class support for steady-state evolution via the new
SteadyStateEvolutionEngine. In steady-state evolution the population is evolved one member at a time rather than all members in parallel. This was possible in previous versions of the Watchmaker Framework but only via a nasty hack.
Island Model Evolution
The major new feature in 0.7.0 is support for island model evolution. Instead of evolving a single population, you evolve multiple populations in parallel. The idea is that the different populations will randomly proceed in different directions making it less likely that the evolution will get stuck at a local optimum. What makes this different from simply evolving a single population multiple times is that there is periodic migration of individuals between islands. The motivation behind the migration is that combining independently evolved individuals with different traits will hopefully result in even fitter offspring. There’s a lot more detail that I’m glossing over that I intend to cover in a later post, but if you want to get started right away the
IslandEvolution class is the place to start.
0.7.0 also includes a new selection strategy.
SigmaScaling uses the population’s fitness standard deviation to regulate the selection pressure, making premature convergence less likely.