Dear Sean,

Thank you for the guidance. It certainly looks easier than I had
originally thought. w00t!

I have a couple questions/clarifications (see below).

Thanks again,

On Jul 12, 2005, at 3:57 PM, Sean Luke wrote:

> On Jul 12, 2005, at 3:32 PM, Steve Butcher (Steve-O) wrote:
>> Conceptually, a hill climber is a population of 1 who at each step is
>> compared to the performance of a clone of itself that has undergone a
>> random mutation.
> I think generally a hill-climber has a population of two.  I've had a
> spirited debate with Paul Wiegand about the difference between
> hill-climbing and the 1+1 ES, and it comes down to the assumption that
> a hill-climber's mutator is "local" -- it cannot mutate to every
> possible spot in space in a single jump.
> Here's a 1+1 mutation-only ES for the ec/app/sum problem.  It's using
> VectorMutationPipeline which could in theory mutate to any point in
> space, but you could replace it with a true "local" hill-climbing
> mutator if you so desire.

I'm a bit confused on this point. The two most common ways to
implement mutation in a vector-based individual are either (1) for
each individual, on some probability, flip a random bit (clearly
local) or (2) for each individual, for each bit, on some probability,
flip the bit (probably not "local"). Which method does
VectorMutationPipeline use?

I can't think of why it would be any other way but is the child
always a mutation of the parent (even at initialization)?