Posted in Software Development by Dan on September 23rd, 2009
A thought for the day, courtesy of Landon Dyer (no relation) a.k.a DadHacker.
“Good programs do not contain spelling errors or have grammatical mistakes. I think this is probably a result of fractal attention to detail; in great programs things are correct at all levels, down to the periods at the ends of sentences in comments.”
Posted in Evolutionary Computation, Java by Dan on September 17th, 2009
In the days before the Watchmaker Framework the two most popular Java evolutionary computation libraries were probably ECJ (Evolutionary Computation [in/for] Java) and JGAP (Java Genetic Algorithms Package). Since the advent of Watchmaker the two most popular Java evolutionary computation libraries are probably ECJ and JGAP. So that worked out well then, but at least the Watchmaker Framework is now being mentioned alongside these established projects.
A recent series of posts over at the Hidden Clause blog compares the pros and cons of implementing the same genetic programming (GP) examples using each of the three frameworks. The article about the Watchmaker Framework is here. In the final analysis Watchmaker is ranked second, ahead of JGAP but behind ECJ, with mostly positive comments (particularly in respect to Watchmaker being the only one of the three frameworks that takes advantage of Java 5’s generics).
Ultimately it seems that the lack of specialist GP support is the main black mark against Watchmaker in this review. Watchmaker is, in its current incarnation, a more general-purpose evolutionary computation framework rather than a specialist system for genetic programming. There is proof-of-concept GP code included but the classes are not part of the core framework. Eventually I would like to include proper GP support, either as part of the core library or as an official add-on library.
I understand that there will be further articles on GP in Java (using ECJ, JGAP and Watchmaker) at Hidden Clause, so it might be worth subscribing if you are interested in this kind of stuff.
Posted in Evolutionary Computation, Java by Dan on September 13th, 2009
This is a bug fix release that addresses a couple of issues with thread management. In version 0.6.1, if you were creating and discarding multiple ConcurrentEvolutionEngines, the threads from the discarded engines would not be cleared up properly. This could eventually lead to OutOfMemoryErrors if you created a large number of evolution engines.
In version 0.6.2, all ConcurrentEvolutionEngines share a common thread pool so there is no need to create and destroy additional threads.
0.6.2 also reverts the switch to non-daemon threads in version 0.6.1. If you were having problems with the JVM not exiting when your program completed, this should fix it.