Re: Semi-Automated Programming

Eugene Leitl (eugene@liposome.genebee.msu.su)
Sun, 18 Jan 1998 12:58:30 +0300 (MSK)


On Sat, 17 Jan 1998, Peter C. McCluskey wrote:

>
> I see no sign that these are significant impediments to the usefullness
> of GA/GP's. CPU time appears to be the biggest problem. Last I heard, Koza

Alas, many systems are intrinsically brittle in regards to mutations (no
neutral mutations, most mutations catastrophic -- the system randomwalks
in a chaotic fitness landscape). E.g. mutating processor instructions is
worse than mutating a subset of the same instructions, which is worse than
mutating a subset of SEXPR's. Which is worse than.. say mutating
connectivity in automaton networks with a certain Hamiltonian. The chance
of an ad-hoc system being near-optimal in regards to GA-optimization is
nil. If you allow the mutation function to mutate (quis custodiet...), it
will just gloss over the ugly edges with time. However, simply (well, it
is maybe not sooo simple) searching for the optimal system's parameters,
subsequently implementing them in dedicated hardware appears easier. As an
aesthete, I just don't believe in long-term usefulness of systems with
hidden holes.

> had a 64 processor system, and was waiting hours if not days for a typical
> run to finish.

Speed is another _major_ bottleneck. However, speed without proper
mutation fitness landscape brings nothing.

> And of course, translating abstract problems into fitness functions
> is not a trivial programming task.

Of course. While coding a robot arm GA-learn the inverse kinematics
appears easy, higher problem-solving skills are not.

'gene

> --