ECJ-INTEREST-L Archives

June 2012

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:
Andreas Meier <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Sat, 30 Jun 2012 07:12:18 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
Hi Sean,

On Fri, 29 Jun 2012 16:43:18 -0400, Sean Luke <[log in to unmask]> wrote:

>On Jun 28, 2012, at 5:36 AM, Andreas Meier wrote:
>
>> I just replaced the lines as you have stated, but now, I get
>> NullPointerExceptions sometimes.
>
>Sorry, my bad.  I wasn't setting the Fitness.  Anyway, I forgot there's a more proper ECJ method for creating a blank new Individual.  Try this 
line:
>
>DoubleVectorIndividual v =
>	(DoubleVectorIndividual)(state.population.subpops[subpop].species.newIndividual(state, thread));
>

I changed it and it now works like a charm: no more NullpointerExceptions.

>Well first things first: at present the DE package cannot do multithreaded breeding at all -- it simply ignores that parameter.  Thus the only 
thing that could be causing the problem is multithreaded evaluation.  However ECJ's evaluator breaks the subpopulation into chunks, one per 
thread, in a deterministic way, and then hands each chunk to a thread to evaluate with its own random number generator.  This means that 
there are only two possibilities:
>
>	1. a bug in ECJ
>	2. a race condition bug in your evaluation code which is causing you to use the same RNG or some other common variable from multiple 
threads.
>
>The ECJ threading code is pretty simple and has been banged on a lot.  So before we look into #1 as a possibility (and it's always a 
possibility), you might check to see if your evaluation code has any race conditions.  In particular, are you using random[thread] or are you 
doing something like random[0]?
>
>Sean

Okay, I didn't know that multithreaded breeding isn't possible right now, but I left this parameter unchanged as all the other ones.
At first I also thought it could be a race condition in my evaluation code. I do not use any RNG inside my code so the only option left would be a 
shared resource with concurrent read/write accesses. Furthermore, I don't know how ECJ handles multithreading internally, whether it has only 
one general problem instance or one instance per thread. In the first case, a shared resource could be a problem, but not in the second case as 
I have no static variables and thus every instance has its own objects. As for the former case, I made a quick hack by extending the evaluate 
method with "synchronized". In my understanding, only one thread is now able to execute evaluate simultaneously. However, I still get different 
results when I repeat the runs. It's not always the case but it occurs quite frequently.

Do you have any ideas how to tackle the problem?

ATOM RSS1 RSS2