ECJ-INTEREST-L Archives

December 2005

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:
Thu, 29 Dec 2005 17:43:25 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
On Dec 29, 2005, at 5:21 PM, Peter Drake wrote:

> FIRST QUESTION:
>
> Is it true that the setting below will evaluate the individuals in
> groups of two, with each individual in one group?
>
> eval = ec.coevolve.CompetitiveEvaluator
> eval.style = rand-2-ways
> eval.group-size = 2

Liviu is our coevolution man, but I believe this will do the following:

For each individual i in the population
        If the individual has not yet had GROUPSIZE evaluations
                Pick a random individual j from the population that
                        has not yet had GROUPSIZE evaluations
                evaluate i and j together once, assigning fitness to each

Sometimes it happens that there's no one on left to evaluate against,
in which case a random person j is chosen and his fitness is not
assigned.


> When an individual is copied, is the copy marked evaluated?  I don't
> seem to be retaining the fitness individual from the previous round.
> Specifically, given the problem class described below, the "residual
> fitness" message is never printed.  Any ideas why this might be
> happening?
> (In the params file, I've got "pop.subpop.0.species.crossover-
> prob      =
> 0.1".)

During breeding, except for a few GP modifiers which had a bug in
them, individuals modified to the next generation should be marked as
not evaluated.  Individuals which are direct copies will be marked as
evaluated.  However CompetitiveEvaluator will evaluate individuals no
matter how they're marked.

Your GoProblem example is odd though: it appears in
postprocessPopulation you're just trimming fitnesses to between 0 and
100.  Why would you want to do that?

Sean

ATOM RSS1 RSS2