Evolving a warrior for Rnd9
Round 9: The Limited-Value Round of the
Redcoder's Frenzy tournament is due to
take place on April 26th, 2003. This gives me a couple of days (Easter holidays and business trips
get in the way). I hope to repeat my luck from a previous
round. Although this time I am not so sure; I aren't using Species for
2003-04-16 Wednesday: Day 1
This round has some serious constraints:
|The values must be -1,0,1
||Easy to adjust the framework to only generate these
|The core is 55,440
||A fight will take forever! Evolving conventionally will go really
|There are only 100,000 cycles
||Not much time; a .33c stone will never cover the whole
The other factors such as processes and warrior length are less important.
Dave Hillis has discussed evolving approaches to overcome these constraints on
r.g.c. His idea was to evolve on a small core, and then see what runs on a
bigger core. It might be a viable approach.
However, Dave's approach isn't the one I'll be taking. I am throwing away the
book on 'fitness', and doing something entirely different for this round! It remains
to see how effective it is.. (both as a concept and my implementation.)
First, fitness. Conventionally a warrior is graded on fitness by fighting other
contestants. Sometimes this is other evolved warriors, sometimes benchmarks are
scattered in there too. Now to get an accurate fitness you need to fight many times;
the more times the better. For good results in Species, I was fighting over 300 rounds
per warrior vs. warrior battle. The bigger the core and the more processes allowed, the
longer each battle takes.
However, what is 'fitness'? Normally a population of warriors evolves in some
random direction. But what if I turn that around? What if I decide on the type of
warrior I want to evolve, and grade the fitness of a warrior upon it's relative
closeness to this ideal?
I have decided I want to evolve a core clear. Maybe this isn't the strongest best
choice for this round, where I expect to come against smart switchers and other mega-beasts. On the other hand, it is easy to evolve
and easy to grade for fitness in the way I describe below:
So I run the warrior once, and then examine the core. I grade the core upon the amount
of mess the warrior has caused. This is my 'fitness'. Each warrior need only be run once
to calculate this fitness, and it need not 'fight' any other warrior. Very fast :-)
My grading of the mess is quite scientific. I value dat bombing over djn trains. I
favour bombs that are 1,1 (as this makes djn-trains slow; for example, dclear can lose
some processes to such a bomb). I value a core that has seemingly been double djn'ed over
one that has only been djn'ed once. etc. I don't examine how a warrior works, I
examine what it achieves. It will be interesting to see what comes up!
For this round, my evolver framework is very very simple. It is a slightly hacked
version of Exhaust, a reasonable
prng and a Warrior c++ class. I can almost view the rnd9-specific framework that I've
bolted onto Exhaust in a single page; major difference compared to the complexity of
the Species framework!
2003-04-17 Thursday: Day 2
My rnd9 evolver is generating several warriors per second. The debug console output
is seriously slowing it down; I'll remove that when I am confident of it's functioning.
After a few minutes it finds a proper linear dat-bomber.. very cool :-D There is hope..
2003-05-17 Saturday: Hindsight
I eventually entered two evolved clears. I picked the fittest, of course. Two runs, two found.
I had tweaked the weightings slightly between the runs, producing two different warriors (although the
prng seed is the same in all runs).
My clears did abysmally. Where the blame
lies is unclear. Did I evolve the wrong type of warrior for this round? Did the fact that these
warriors I evolved did not have to fight lead to fagile warriors? Were my clears actually good clears?
Did the fact that they were so long (always 30 instructions, even if not all instructions were relevant)
disadvantage them? Probably, guilty on all counts :-(
But this bad result doesn't conclusively shot-down this concept of fitness-by-core-mess evolving.
I foresee revisiting this strategy another time with a clever mars that can
score during the run, acculmulating a score not by end result by by how that end result was arrived at.