Many thanks to Muhammad Atif Azad, who thoroughly analysed TinyGP.java, the sample GP implementation in one of the appendices of the book, and uncovered another important bug.
In the evolve function the following line of code
if ( rd.nextDouble() > CROSSOVER_PROB ) {
should be
if ( rd.nextDouble() < CROSSOVER_PROB ) {
This bug does not crash the system, but it means that the parameter CROSSOVER_PROB is interpreted as the mutation probability rather than the crossover probability (its intended purpose).
We had found and cured this bug some years ago in the C version of TinyGP, but it somehow made it into the Java version (probably because I did the conversion before the bug had been found).
The bug has now been fixed in the online version of TinyGP.java
My most sincere apologies to any users of this system.
About the book
A Field Guide to Genetic Programming (ISBN 978-1-4092-0073-4) is an introduction to genetic programming (GP).
GP is a systematic, domain-independent method for getting computers to solve problems automatically starting from a high-level statement of what needs to be done. Using ideas from natural evolution, GP starts from an ooze of random computer programs, and progressively refines them through processes of mutation and sexual recombination, until solutions emerge. All this without the user having to know or specify the form or structure of solutions in advance. GP has generated a plethora of human-competitive results and applications, including novel scientific discoveries and patentable inventions.
The book is freely downloadable under a Creative Commons license as a PDF and low cost printed copies can be purchased from lulu.com. This web site will be used for information relating to the book, and other pertinent announcements. We also have a discussion group for questions and conversation related to the book.
Showing posts with label TinyGP. Show all posts
Showing posts with label TinyGP. Show all posts
Monday, 19 January 2009
Tuesday, 18 November 2008
A (potential) bug in TinyGP
Many thanks to Muhammad Atif Azad who found a bug in my implementation of the grow method. Quoting from his email:
Indeed Atif is right: since by default MAX_LEN is set to 10,000, in order for the bug to occur one needs to use very big initial maximum depths so that individuals with more than 10,000 nodes may be created.
The online version of TinyGP (available here) has a fix for this potential bug.
PS: In the original version of TinyGP, the code to perform point mutation replaced terminals with variables. This implied a bias in that random constants were actively removed from the population when mutation was switched on. Atif pointed this out to me recently. The current version of TinyGP does not have this bias.
The 'grow' function returns -1 if we go past the maximum size limit. Consider the following line of code:return( grow( buffer, grow( buffer, pos+1, max,depth-1), max,depth-1 ) );
Let's say the nested grow returns -1. The outer grow accepts it for 'pos' i.e. index to next location in the tree to grow. There is no check inside the function grow against (pos == -1). Thus, it would raise a run time exception if used.
The reason it may not have occurred so far may be that we reach the depth constraint earlier than the size limit.
Indeed Atif is right: since by default MAX_LEN is set to 10,000, in order for the bug to occur one needs to use very big initial maximum depths so that individuals with more than 10,000 nodes may be created.
The online version of TinyGP (available here) has a fix for this potential bug.
PS: In the original version of TinyGP, the code to perform point mutation replaced terminals with variables. This implied a bias in that random constants were actively removed from the population when mutation was switched on. Atif pointed this out to me recently. The current version of TinyGP does not have this bias.
Tuesday, 6 May 2008
Bug in TinyGP Java Code
Sander Land found a bug in the constructor "tiny_gp" of the TinyGP system described in appendix B: the "x" array is initialized (lines 345-346) after the population is (line 344), causing invalid fitness evaluations during the initialization of the population, thereby wasting the first generation. The mistakes has been fixed in the code available here. Many thanks Sander (and apologies to all users).
Subscribe to:
Posts (Atom)
