Russ Abbott wrote:
In a system like this though, you always have to start with some
primitives. It's really matter of where you can get from the
primitives and whether there is a steadily uphill (in terms of
fitness) path for getting there.
That's a question of how diversity is maintained in population and what
kind of transformations are made to the population of programs. If
transformations are modular or there is no mechanism for maintaining
diversity, then a rugged fitness landscape may well cause problems --
the population can reduce to, in-effect, one individual and be stuck in
a rut forever. It's a problem with optimization algorithms in general,
not just genetic programming.
It's not that one can't include a looping structure as a primitive.
It's that GP is not good at using it.
I suspect enhanced evaluation mechanisms are needed to influence
fitness. I speculate that historical human imperative programing
habits aren't particularly helpful either for automated programming
(better to have lambdas bound to names and recursion).
The size of the expression tree has been used in GP for a long time to
encourage parsimonious solutions to be found, but I suspect there hasn't
been much work has been done to provide a cost of a calculation. By
that I mean stuff like L3 cache misses (how irregular is the memory
access pattern?), the maximum depth of the stack pointer (is it
non-terminating recursion?), instructions retired (logically how
efficient is the calculation?), and total joules used (what does it
really take to make CPUs do it?). Optimizing over that space is what
quantifies the difference between good and bad programs..
Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
