I’ve just uploaded version 0.6.1 of the Watchmaker Framework for Evolutionary Computation. If you’re not already familiar with the project, it is a library for implementing evolutionary/genetic algorithms in Java. It’s multi-threaded, cross-platform, fast and has a modern, unobtrusive and flexible API.
API Improvements
One user-requested addition to the API in this release is the getSatisfiedTerminationCondtions method. This makes it easy to determine which termination condition (elapsed time, generation count, stagnation, etc.) caused the evolution to terminate when you are using multiple termination conditions.
The API documentation has also been improved in a few places to make things clearer. Firstly, the framework does not support negative fitness scores. In previous releases it may have worked under some circumstances, but it was undefined behaviour. In this release you will get an IllegalArgumentException if you try it.
Secondly, if you are using an EvolutionObserver to update a Swing GUI, be careful not to overwhelm the AWT thread with updates (this can happen if you are processing dozens or hundreds of generations per second). It appears that the framework is so fast that AWT can’t keep up. If this happens (it’s more likely with small population sizes), the GUI will become sluggish and unresponsive. This problem is mitigated by minimising the work that your EvolutionObserver does on the AWT thread or by only updating the GUI every nth generation.
Distributed Fitness Evaluations with Terracotta
There have also been some internal modifications to make the framework more amenable to clustering with Terracotta. Terracotta can now be used to distribute the workload across multiple machines. It’s only at the proof-of-concept stage at the moment – there is no support for handling node failures. It’s also only really worthwhile for evolutionary programs that have expensive fitness functions. The fitness function has to be expensive enough to justify the cost of transferring the candidate across the network for evaluation on another machine, otherwise clustering just makes things slower.
I will likely provide more detail on how to use Watchmaker with Terracotta in a future article, but for now here’s what to do if you want to try it out. The field that you need to configure Terracotta to share is the private workQueue field in the org.uncommons.watchmaker.framework.FitnessEvaluationWorker class. Run your unmodified program using Terracotta then run extra instances of the FitnessEvaluationWorker on other nodes.
Remember, you also have the option of using Hadoop with Watchmaker (via the Apache Mahout project).
See the changelog for full details of changes in this release.