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.
A parallel network of spiking excitatory/inhibitory automata with a
decaying connectivity on 3d lattice will clearly perform better here,
because (provided you also evolved the properties of individual
automata classes and the way the connectivity is being modified) it
typically homeostates its total energy (an equivalent of epilepsy
would be fatal in an industrial control application) nicely and tends
to degrade gracefully, when parts of it fail incrementally or are
being mutated.
> validation and extendability seem likely to suffer. How do you evolve
> an operating system or traffic controller that you trust? Even if the
The notion of an OS has obviously to be revisited. You need something
which lets you run your evolutionary algorithms on a given
hardware. This basic set of patterns/virtual hardware infrastructure
is your "OS". It is not necessarily something which needs to be
evolved.
You train a behaviour in a reality simulator or wiring the output to
the physical incarnation of machinery the circuit is going to control,
if an occasional mistake is affordable. A robot spray-painting a car
chassis needs to finish the best job in minimum time and movements
using the least amount of paint while not whacking into itself and
other things. Here you obviously have to use a reality simulator,
because the training process will either result in a mess or lots of
broken hardware or both. Once the system has developed a feel of self
and surroundings (or means to see, and understand that a hard surface
is something to avoid if you move at high velocities), you can leave
it out of its virtual playpen and let it fine-tune the learning on the
factory floor (due to its limited fidelity a reality simulator is only
good for coarse learning). Similiar things apply to a pilotless
fighter training a dogfight, only in a larger extent: hundred
megabucks worth of hardware are potentially at stake here.
> process is interactive, it seems to require a high degree of skill and
> ways of examining messy evolved code.
Examining messy evolved code? Simple: you don't. (Unless you want to
learn some new tricks on a particularly simple example --
understanding more complex ones is difficult since they're doing
something nontrivial, orelse you wouldn't bother with making them in
the first place). You just have to sample the input space
representatively, and prove statistically that the given set of
outputs (system behaviour) meets your specs. This is not particularly
different from today's quality control, since formal proofs are rarely
employed in the software industry reality.
Evolutionary computation is obviously no panacea (though, as a
metamethod it can generate other methods, and is in principle
open-ended -- but we're not talking about operating in that
high-falutin' regime yet), but it can come very handy in a large class
of solutions typically painstakingly coded by highly paid specialists,
and result in less than satisfactory performance (navigation and
robotics, complex control, etc).
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:50:17 MDT