<div>Off topic</div><div><br></div>I was deeply involved in genetic programming in the past (in fact I discovered Haskell on looking for a functional language for genetic programing with better syntax than LISP).<div><br>
</div><div>But I soon realized that GP was not the holy grial after all. The problem with evolving arbitrary programming code is the <a href="http://www.google.com/search?hl=en&q=fitness+landscape">fitness landscape</a>. Any evolutionary process needs a way to produce small changes that produces small increases or decreases of fitness (parsimony). This is why it is relatively easy to evolve a continuous function towards a desired value. A smal change in a parameter has a small effect in the resulting fitness, so the algoritm can step up trough the smooth fitness landscape upto a local maximum.</div>
<div><br></div><div>But programs are non lineal. If I change the expression in a conditional, the flow of the program becomes radically different, so the fitness landscape, instead of a smoth continuous surface is a fractal where there are no way to climb up the mount improbable (Dawkins dixit).</div>
<div><br></div><div><a href="http://www.google.com/search?hl=en&q=mount+improbable+dawkins">http://www.google.com/search?hl=en&q=mount+improbable+dawkins</a> </div><div><br>The only way to overcome this is to indentify the smooth parts of the fitness landscape and restrict the exploration to them trough some techniques such is the use of rules, division of the problem in subproblems and ...well any trick programmers use in their ordinary work to restrict and direct the program mutations.</div>
<div><br></div><div> It is theoretically possilble to define metalevels of genetic algoritms where rules and strategies are selected by extracting sucessful patterns after evolving a big number of sucessful programs, These metaleves can discover from simple rules such are "if a push is inserted, a pop must be inserted somewhere else (push-pop gene mutation rule), upto the re-discovery of complex rules above mentioned. These rules later would be used to restrict the mutations of the lower levels. Finally the rules could become so accurate that no mutation at the lower level is necessary because the evolved higuer level rules give the solution at the first try. So the genetic algoritms have the potential to design arbitrary complex programs right from scratch, but it may require a few billion years of computing.</div>
<div><br></div><div>Anyway this stuff is really interesting and I suspect that the combination of rules and metalevels has some future, at least for helping programmers with intelligent IDEs.</div><div><br><div class="gmail_quote">
2010/12/8 Kenneth Hoste <span dir="ltr"><<a href="mailto:kenneth.hoste@ugent.be">kenneth.hoste@ugent.be</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Jan,<br>
<br>
Hi Jan,<br>
<div class="im"><br>
On 11/29/2010 12:55 PM, Jan Snajder wrote:<br>
> Dear Haskellers,<br>
><br>
> I am pleased to announce the release of genprog-0.1, a genetic<br>
> programming library.<br>
><br>
</div>> (snip)<br>
<br>
Very interesting, and nice job on the code (elegant, well-structured,<br>
well-documented, ...)!<br>
<br>
Genetic programming recently got my attention because one of the bots in<br>
the Google AI contest was built using this technique (see<br>
<a href="http://ai-contest.com/forums/viewtopic.php?f=17&t=1136" target="_blank">http://ai-contest.com/forums/viewtopic.php?f=17&t=1136</a>), and it<br>
performed really well (way better than my hand-crafted bot).<br>
<br>
I have a bit of experience with genetic algorithms, on a practical and<br>
pragmatic level. The field of genetic programming is something I hope to<br>
look at and play with in the upcoming months (just for fun).<br>
<br>
I was kind of planning to implement my own genetic programming library<br>
in Haskell as I became familiar with the field, but after diving into<br>
your code it quickly became clear to me you've done a way better job<br>
than I would have.<br>
<br>
I really like the example you provided for evolving an expression that<br>
computes a specified integer value. I plan to start playing with that<br>
and improve the example (faster convergence to a perfect solution, and<br>
also tweaking the current GP config to obtain smaller solutions).<br>
<br>
<br>
A couple of questions (some fairly unrelated to Haskell):<br>
<br>
How hard would it be to extend the current version to support the<br>
evolution of actual Haskell programs? As far as I can tell, the current<br>
version has support for (simple?) self-defined expressions, but this<br>
seems like a long way from supporting Haskell programs with<br>
multi-argument functions that operate on lists, etc., even if you just<br>
limit it to non-monadic Haskell98 code.<br>
<br>
Have you considered playing with dynamic values for the various<br>
parameters that steer the evolution, i.e. population size,<br>
crossover/mutation probabilities, etc.?<br>
One thing I've always wanted to try (but never really got to it) is e.g.<br>
increasing the mutation probability as the evolution seems to be getting<br>
stuck in a (local?) optimum. Also, shrinking the population size if<br>
enough progress is being made could be interesting, to speed up the<br>
evolutionary process. Are you aware of studies that do such a thing?<br>
<br>
Are you planning to actively maintain and extend this library? Are you<br>
using it for research purposes, or did you hack this together just for<br>
fun (if so, nice job!). What do you plan to use it for?<br>
<br>
<br>
Anyway, great job, I hope I'll find the time to play around with this.<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Haskell mailing list<br>
<a href="mailto:Haskell@haskell.org">Haskell@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell" target="_blank">http://www.haskell.org/mailman/listinfo/haskell</a><br>
</div></div></blockquote></div><br></div>