Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of thomas.neidhart@gmail.com
 designates 209.85.212.177 as permitted sender)
Message-ID: <50A4A2F4.7030804@gmail.com>
Date: Thu, 15 Nov 2012 09:08:20 +0100
From: Thomas Neidhart <thomas.neidhart@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: dev@commons.apache.org
Subject: Re: [Math] "FixedElapsedTime" in genetic algorithm (Was: svn commit:
 r1409352 - ...)
References: <20121114200952.587E82388993@eris.apache.org>
 <20121115000556.GJ3397@dusk.harfang.homelinux.org>
 <50A43997.8060601@gmail.com>
 <20121115012337.GK3397@dusk.harfang.homelinux.org>
In-Reply-To: <20121115012337.GK3397@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 11/15/2012 02:23 AM, Gilles Sadowski wrote:
> On Wed, Nov 14, 2012 at 04:38:47PM -0800, Phil Steitz wrote:
>> On 11/14/12 4:05 PM, Gilles Sadowski wrote:
>>> Hi.
>>>
>>> On Wed, Nov 14, 2012 at 08:09:52PM -0000, tn@apache.org wrote:
>>>> Author: tn
>>>> Date: Wed Nov 14 20:09:51 2012
>>>> New Revision: 1409352
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1409352&view=rev
>>>> Log:
>>>> Reduce sleep time in unit test to prevent possible race condition.
>>>>
>>>> Modified:
>>>>     commons/proper/math/trunk/src/test/java/org/apache/commons/math3/genetics/FixedElapsedTimeTest.java
>>>>
>>>> Modified: commons/proper/math/trunk/src/test/java/org/apache/commons/math3/genetics/FixedElapsedTimeTest.java
>>>> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/genetics/FixedElapsedTimeTest.java?rev=1409352&r1=1409351&r2=1409352&view=diff
>>>> ==============================================================================
>>>> --- commons/proper/math/trunk/src/test/java/org/apache/commons/math3/genetics/FixedElapsedTimeTest.java (original)
>>>> +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math3/genetics/FixedElapsedTimeTest.java Wed Nov 14 20:09:51 2012
>>>> @@ -59,7 +59,7 @@ public class FixedElapsedTimeTest {
>>>>  
>>>>          while (!tec.isSatisfied(pop)) {
>>>>              try {
>>>> -                Thread.sleep(500);
>>>> +                Thread.sleep(50);
>>>>              } catch (InterruptedException e) {
>>>>                  // ignore
>>>>              }
>>>>
>>> I have never read this part of CM yet. But just this makes me think that the
>>> "FixedElapsedTime" class should not exist in CM. Indeed, using it makes the
>>> algorithm behave differently at each run!
>>> I don't deny the usefulness of allotting some amount of time for a
>>> computation, but this has absolutely nothing to do with genetic algorithms
>>> (nor any others).
>>> CM can help in implementing this high-level requirement, by allowing
>>> <some search algorithm> to be restarted with the result of a previous run
>>> but IMHO it is a bad idea to have the various CM codes directly implement
>>> that functionality.
>>
>> I disagree.  This looks like a useful feature to me, contributed by
>> a user.  GA algorithms are by nature iterative with run-time
>> evaluated StoppingConditions.  FixedElapsedTime is a reasonable
>> stopping condition supported by other GA frameworks.  The feature is
>> well-documented, so users know exactly what it does.  In particular,
>> the number of generations is not fixed, so using this
>> StoppingCondition does not guarantee the same results on successive
>> runs with the same input parameters.  GAs are often
>> non-deterministic for other reasons (randomness in mutation), so
>> this is not a practical issue for those choosing to use the feature.
>>
> 
> This one is really not worth a fight, but something which you have to adapt
> depending on the machine on which you run your program can only be qualified
> as a toy feature (IMHO): Unless we talk about real-time processing (which GA
> are not really suited for...), some fixed amount of time can be too small
> (solution not found on a "slow" machine) or too large (solution found long
> before the end of the alloted time slot, but the algo keeps the CPU busy).
> 
> As for "non-deterministic", we had several discussions on this ML about
> being able to control the pseudo-random behaviour of the algorithms, by
> using a fixed seed. This is the same here, should you use the same seed,
> the search should go through the same steps. But in this case, it is
> _impossible_ to reproduce the same result since the number of generations
> will depend on how busy the machine is with other processes.

tbh I do not see the issue here.

As Phil pointed out, this is a commonly used stopping condition for GAs
so it makes sense to have it supported by default.

I do not see the link to a discussion about deterministic behavior of
algorithms. It is much more similar to a fixed iteration count (a
stopping condition that already exists), whereas in this case it is
time-based (if a user prefers it this way).

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org