Eugene Leitl wrote:
>
> Anders Sandberg writes:
>
> > The question is how good the resulting code will be. Obviously, it
> > won't be brittle - in fact, you have to find ways of coding that
> > aren't brittle even in order to evolve code - but modularity,
>
> Indeed. In fact this was the reason I said "grow a solution" instead
> of "grow a program", as von Neumann type machine code doesn't meet two
> most important criteria of a successful evolvable design: if we assume
> a computer program mapping some input space to output space the space
> of all possible programs is not percolated with long neutral-fitness
> filaments (in fact quite the opposite, as most bit mutations will
> break it horribly), and not entire mapping diversity can be found
> within the volume of a small ball from some random point in program
> space. This can only be partially compensated by a complex mutation
> function, which traipses around the most obvious minefields and
> potholes of the system (jumps are dangerous as is division, absolute
> jumps are more dangerous than relative ones, as are tests,
> etc.). Obviously not an elegant solution, if a solution at all.
Except for maybe extremely small algorigthms I would never set up a code
evolution much less a code construction program to randomly twiddle
bits. Rather it would attempt different recombinations and orderings of
higher order constructs. It would work at the instruction level at the
smallests, sets of instructions performing useful subfunctions,
function, object, component level. You need wasy to decompose the
problem to be addressed and to describe the semantics of the pieces in a
computer/human meaningful way to get larger scale code construction. GA
at the level of alternate designs and implementation paths rather than
at the level of bits.
- samantha
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:50:17 MDT