Who can do genetic programming with Python

[Martijn Faassen]

Erik Max Francis <max at alcyone.com> wrote:
> Martijn Faassen wrote:

>> Cool; I've recently been thinking about that. Any results, info, etc,
>> you
>> have on your experiments?

> They look to be at least as good as using LISP as the genetic language
> as in Koza's work.  How you repopulate the population each generation
> can get tricky, however; a wholesale approach can lead to diversity
> problems.  A stabilizing approach is during the fitness tests to
> randomly select two programs, evaluate their fitness (perhaps by trial
> against each other), then perform crossover and mutation and replace the
> less fit program with their offspring (and doing this n times in a
> population size of n you call a generation).

> Even though this seems strange at first, it's really necessary since
> diversity problems (where many of the programs start resembling each
> other) can lead to a degenerate case where more and more resemble each
> other with small defects; after a few generations programs start looking
> like stutterers (a bunch of programs that look like A B C D E will
> result in programs that might look like A B B B D C C D D C D D E ...).

You can probably do something about that making instructions cost something. :)

> There's a paper called "Stack-based genetic programming" by Perkis I
> could send you (via email) if you're interested.

Very interesting. Please do.

>> I've worked with a simple virtual machine designed to the same
>> constraints too (every sequence of instructions is a legal program),
>> but this VM didn't have a stack *or* a set of registers; instead there
>> were some instructions to move read/insert/delete heads onto their
>> own instruction set. This allowed me to write an ancestor replicator
>> would
>> copy itself. That's different from genetic programming though, moving
>> more towards artificial life.

> I also have another artificial life system that involves a virtual
> machine language as well, although it has a full instruction set,
> registers including some shared registers, the ability for processes to
> fork into new ones, always-legal instructions (well, illegal
> instructions set an exception register, but they don't halt the
> process), indirection, and an assembler with labels support (!).

Hm, so what evolves? :) My system has the ability to fork as well (in
fact that is a necessity). A replicator exists in space on a grid,
can move around and gather resources. Using the resources it can
scan itself, copy itself to another area of the instruction string and
finally create another processor for it and split off the offspring into
another location. What evolves are generally systems to gather more
resources and survive crowding conditions. A new 'organ' which consists
of a doubly nested loop evolves which does that. 

> The two systems are called Qu and Jupiter, respectively, by the way;
> I've been planning on releasing them publicly for quite some time but
> haven't quite had the energy to package them up.  Maybe someone with
> sufficient interest in playing could light a fire under my butt.

I have the interest, but perhaps not the time. My system is called Cielo
(as it's in the Tierra/Avida line of experimentation), and is a bunch of
rusty C++ code which I'm not sure I want to release. :) I keep
thinking about writing a new simulation though adding some of the
ideas I've had later. I'm especially interested in adding some concept of
genes (as a functional unit) to the simulation. Multiple genes would run
in parallel in any individual and contribute to its global behavior.
This way, a deletirious mutation in one gene may not necessarily result 
in a breaking of the individual (if there are other copies of the gene
without the mutation still running), hopefully helping to smoothen the
fitness landscape and creating more diversity.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?