ECJ-INTEREST-L Archives

December 2007

ECJ-INTEREST-L@LISTSERV.GMU.EDU

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

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

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Sun, 2 Dec 2007 17:17:27 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
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