Evolving Applications with Genetic Programming

As I write this schuschGP runs steadily in the background, recombining and mutating thousands of little programs. I’ve been playing with the program for a while now, but it’s taken a bit of time to really understand it, especially because the syntax of scheme still can throw me for a loop (plus Lee had to point out a few really obvious, glaring errors that I was skimming over).

Right now I’m trying to evolve a program which does a different mathematical function depending on what virtual key is pressed; in the current iteration, a virtual keypress of ‘k’ should simply print the input integer, while a keypress of ‘not k’ should produce the input plus 3.

It has yet to succeed, but it’s getting there. The very first functional run of the complete fitness function produced, after a few generations, this bit of code: (in integer.fromboolean integer.+ code.do*). It doesn’t look like much, but it has a few elements suggesting some degree of success – the instruction “in”, for example, is one which I added to the code generator which gets the keypress and adds it to the boolean stack, which is why seeing ‘fromboolean’ is also a good sign. Since then it’s only been improved.

A lot of previous missteps have been informative. For example, initially the two things the code was supposed to be able to do was either add or multiply. The problem is that multiplication produces larger and more varied values, while addition (for a set range of digits, of course), produces a smaller range of values. The success of the program is measured, primarily, by the difference between the correct result and the actual result; multiplication had more potential to produce a larger difference, and so addition was always favoured, and the programs would add but stalwartly refuse to multiply.

A better solution, it seemed, was to create something which, no matter which keypress was evaluated correctly, would have the same error value as the other keypress. Printing the input with a keypress of ‘k’ and subtracting 2 from the input on a keypress of ‘not k’. In most cases, this would produce a symmetrical error weighting, except in the case of the number 1. In a ‘not k’ case with this error function we perform 1 – 2 = -1. A a negative error value would imply a better answer than the right answer, however, so we have to take the absolute value of this number, producing a value of 1. In a ‘k’ case, we simply print 1. Because the answer to both is one, a false positive occurs. Any program which can print 1 in any way has the potential to succeed. The computer seemed to like taking the length of the code stack and calling it a day.

Similar missteps were abound (for a while I tried storing keypresses as integers, 0 being one button and 1 being another, until I realized it was extremely easy for a program to just print the keypress value and, if it was zero, immediately succeed. They’re Boolean now) but things are off the ground now.

-Nate

This entry was posted on October 7, 2009 at 12:09 am and is filed under Uncategorized.