ECJ-INTEREST-L Archives

December 2007

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Mon, 3 Dec 2007 10:10:57 +0000
Reply-To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Subject:
From:
David Robert White <[log in to unmask]>
Content-Type:
text/plain; charset=US-ASCII; format=flowed
In-Reply-To:
MIME-Version:
1.0
Comments:
To: ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (76 lines)
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...

ATOM RSS1 RSS2