On 11/15/2012 09:08 AM, Thomas Neidhart wrote: > 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, t...@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).
I just re-read my post and wanted to clarify: * the algorithm is deterministic * the result of course not, as it depends on the number of generations So you are right, getting the same result with such a stopping condition is indeed tricky, but sometimes this is not the goal. You just want to get the best solution so far, even if it is not the best possible. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
