It's not a big deal, you could easily compute it in Evaluator. But
to my mind, evaluation's job is to compute the actual fitness of an
individual. Breeding and selection's job is to determine what to do
with those individuals. Fitness sharing is, in some sense, a hack
meant to adjust how the selector picks individuals despite their
fitness. So for me that feels like it ought to go into breeding.
Also by doing it in the breeder, you can avoid having to customize an
Evaluator that's already been customized for some other purpose (I
customize evaluators much more than breeders).
If you're doing island models, there's another reason. The island
model loop more or less goes like this:
Send of individuals to islands
Receive individuals from islands (killing a few that you just bred)
So if you did it in Evaluate, then you just modified the fitness of
individuals you're sending off to other islands, which they may or
may not appreciate.
Again, it's not a big deal.
On Dec 3, 2007, at 5:10 AM, David Robert White wrote:
> Sean - could you possibly expand on why it would be a poor choice
> to implement fitness-sharing statistics (and other such measures)
> in an Evaluator? Conceptually, the evaluator would seem like a
> sensible place, as it does seem like part of the evaluation of an
> individual's fitness.
> It would be helpful to hear more as I'm having to make similar
> design decisions and I'm sure others are too.
> Sean Luke wrote:
>> We don't have it by default; you can probably do it in one of
>> three ways:
>> 0. Make a special Fitness which stores the "real" fitness as a
>> backup number, and uses the standard fitness value as the
>> "perceived" fitness. Then create a custom breeder which goes
>> through the population and adjusts all the fitnesses with respect
>> to niching and the "real" fitness prior to breeding.
>> 1. Make a custom breeder which goes through the population and
>> adjusts everyone's fitness, not keeping the old "real" fitnesses
>> around, but just modifying them on the spot.
>> 2. Make a custom tournament selector (or other selection method)
>> which rolls in the "perceived" fitness on the fly.
>> #1 will be the easiest but may lead to bugs (see other options
>> below). However, it has the disadvantage of modifying the fitness
>> of individuals. If your individuals make it into the next
>> generation, their fitness will *again* be modified, which you
>> probably don't want. This will occur if any of the following are
>> - you're using a straight reproduction pipeline
>> - your crossover operator is set to push parents through the
>> crossover if the crossover is "invalid" (if you're using GP and
>> you have too deep a kid, for example)
>> - you're pushing individuals to other subpopulations, in an island
>> model fashion, or to islands on other processors
>> Generally you can get around it by having ECJ always reevaluate
>> every individual and update its fitness even if it's already been
>> set. The easiest way to do this is to have your Problem ignore the
>> 'evaluated' flag and always evaluate individuals regardless.
>> You may still need to think about the logic of when individuals
>> come in from other islands if you're doing island models. When an
>> individual comes from another population it may already have had
>> its fitness adjusted. You would like to make sure it doesn't get
>> adjusted AGAIN before breeding in your population.
>> #0 will lead to the fewest bugs, because it doesn't have any of
>> the issues described above -- your evaluator always resets the
>> fitness based on a fixed "real fitness".
>> #2 I don't recommend, too complex.
>> At any rate, no, do it in Breeder before you go breeding. I'd not
>> do it in Evaluator.
>> On Dec 2, 2007, at 2:47 PM, Christopher Vo wrote:
>>> I would like to do fitness sharing in ECJ, where the perceived
>>> fitness of an
>>> individual depends on how many individuals occupy that same niche
>>> (a niche
>>> being perhaps defined by some phenotype distance metric, etc.).
>>> Is there a simple way of doing this in ECJ? I was thinking of maybe
>>> extending ec.Evaluator...