ECJ-INTEREST-L Archives

August 2006

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:
Wed, 23 Aug 2006 16:45:10 -0400
MIME-version:
1.0 (Apple Message framework v752.2)
Reply-To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Content-type:
text/plain; charset=US-ASCII; delsp=yes; format=flowed
Subject:
From:
Liviu Panait <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7bit
Comments:
To: ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (52 lines)
Sorry for the late response, but the last days before the final  
defense have really gotten to me.

There was indeed not much in ECJ that resembled what you wanted to  
do, but the entire design of the system was such that you could  
easily build it yourself.

One advice I have for you is to pay extra attention to what you're  
experimenting with.  One problem I see with coevolution is that it's  
very easy to write a bit of code, then debug it for weeks/months to  
figure out why it is not working.  The problem is not that there are  
bugs in the code, but rather that what you end up coding may not  
search for the kinds of solutions you thought it is searching.   
Coevolution is a different beast from evolution, and algorithmic  
decisions that might make sense for someone might actually have a  
huge impact (positive or negative) on the behavior of the algorithm.   
For further reading on such topics, I'd suggest Paul Wiegand's PhD  
thesis from 2004, or, more recently, mine, which I could send to you  
directly if you're interested.  My entire thesis is about why certain  
algorithmic decisions might make your cooperative coevolutionary  
algorithms (as well as other concurrent multiagent learning  
algorithms) go berserk, as well as about how to design new algorithms  
that search for better solutions.  Given your interest in competitive  
coevolution, I'd also suggest you check out (if you have not already  
done so) the work of Bucci, de Jong, and Ficici from the past years.

Best,

Liviu.

On Aug 23, 2006, at 4:27 PM, Robert Baruch wrote:

>
> On Aug 22, 2006, at 8:06 PM, Sean Luke wrote:
>
>> Hi Robert, we're not actively avoiding you!  :-)  I'm in Kyoto on  
>> very limited bandwidth, and Liviu's working on his dissertation  
>> (which he's defending in a few days).  Liviu's the man you want to  
>> have look into this anyway -- he wrote the coevolution code and  
>> knows it better than I do.  Give him a little while though!  :-)
>
> That's ok :) I finally realized that what I wanted was something  
> like CompetitiveEvaluator, but not quite, and something like  
> MultiPopCoevolutionaryEvaluator, but not quite. So I wrote my own  
> evaluator, just enough to get it working.
>
> Here it is, for your amusement. Someone could probably take it and  
> turn it into something worthy of inclusion in ec.coevolve.
>
> --Rob
> <RandomOpponentEvaluator.java>

ATOM RSS1 RSS2