Thanks for that.  I thought the island model issue would be the main 
problem.

As the island model is asynchronous, would fitness sharing still be 
meaningful?  I guess it might.

If we're sharing individuals that are "good", we'd probably want to 
share those occupying niches, so these niches could then be explored by 
multiple islands.  So it would be nice to separate standard fitness from 
such niching fitness measures, and have separate evaluation for both of 
them.  This would allow re-evaluation of fitness sharing after 
migration, without re-evaluating standard fitness.  Is there a nice way 
of doing this?

I know it's not a big deal... :-)  I have been working on MOA for ECJ 
and at the moment my code won't work with islands due to this issue.

Cheers

David

Sean Luke wrote:
> 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:
>
> Loop:
>     Evaluate
>     Send of individuals to islands
>     Breed
>     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.
>
> Sean
>
> On Dec 3, 2007, at 5:10 AM, David Robert White wrote:
>
>> Hi
>>
>> 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.
>>
>> Thanks
>>
>> David
>>
>> 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 true:
>>>
>>> - 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.
>>>
>>> Sean
>>>
>>> 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...