Evolving a warrior for Rnd9

Summary

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 a start..

2003-04-16 Wednesday: Day 1

This round has some serious constraints:

Constraint	Implications
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 slowly
There are only 100,000 cycles	Not much time; a .33c stone will never cover the whole core..

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.