I think so too. Genetic Programming always struck me as quite wasteful because your algorithm doesn't care about *why* any of your offspring succeeded or failed.
Intelligence has been a huge evolutionary boon because it allows critters to learn from the mistakes of others, and then over time those learnings become baked into the genome. (see "how learning can guide evolution": http://htpprints.yorku.ca/archive/00000172/01/hinton-nowlan.htm ) Evolution is really really slow... Which isn't a problem when you're an insect, and the cost of forking a child process is eating a little bit of garbage juice. When you're trying to program with expensive and limited computing resources however, it makes more sense to encode some knowledge into the solution-generating system. On Friday, October 15, 2010, frank <[email protected]> wrote: > > I think genetic programming is probably most interesting if you don't > write a mere battery of black-box tests for the fitness evaluation. > > It would be much cooler to have code that reasons about the candidat > solutions, and see how much of each is proovably correct, IMHO. =) > > Casey Ransberger wrote: > > The previous thread about testing got me thinking about this again. One of > the biggest problems I have in the large with getting developers to write > tests is the burden of maintaining the tests when the code changes. > I have this wacky idea that we need the tests more than the dev code; it > makes me wish I had some time to study prolog. > I wonder: what if all we did was write the tests? What if we threw some kind > of genetic algorithm or neural network at the task of making the tests pass? > > I realize that there are some challenges with the idea: what's the DNA of a > computer program look like? Compiled methods? Pure functions? Abstract syntax > trees? Objects? Classes? Prototypes? Source code fragments? How are these > things composed, inherited, and mutated? > > I've pitched the idea over beer before; the only objections I've heard have > been of the form "that's computationally expensive" and "no one knows how to > do that." > > Computational expense is usually less expensive than developer time these > days, so without knowing exactly *how* expensive, it's hard to buy that. And > if no one knows how to do it, it could be that there aren't enough of us > trying:) > > Does anyone know of any cool research in this area? > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
