|
From: Theuns C. <the...@gm...> - 2009-07-17 12:18:02
|
Agreed, if we decide to always increment the counter, then nobody will wonder about it again. -- Theuns On Thu, Jul 16, 2009 at 10:21 AM, Gary Pampara<gpa...@gm...> wrote: > +1 for this change. > > I agree with the proposed. > > I think that even within a dynamic environment it makes sense. You are > responding to a change, but the amount of work that is required to reevaluate > the current candidate solution is still a fitness evaluation and should result > in an increment of the counter. > > I've never particularly liked the overloaded method with the boolean > parameter. Yes, agreed, it makes the API ambiguous and we should sort it out. > > Regards, > Gary > > On Thursday 16 July 2009 10:11:08 Leo Langenhoven wrote: >> Hi all, >> >> as you know using the number of fitness evaluations as a stopping criteria >> is a common strategy. There is, however, some ambiguity with regards to >> counting these evaluations in the current implementation. If we ignore the >> OptimisationProblemAdapter class for the time being, and focus on the issue >> from the perspective of Entities, then there are currently three methods >> with which you can receive a Fitness value. The first method is getFitness, >> which simply returns the Entity's stored fitness value. The second method >> is calculateFitness (without parameters), which calculates the fitness for >> the Entity's candidate solution, incriments the number of evaluations for >> the problem, stores the new fitness and returns it. The third method is >> calculateFitness that receives a flag which indicates wheather or not the >> number of fitness evaluations should be increased. I propose that we remove >> (or make the method private) the calculateFitness method that receives the >> flag parameter, since this method introduces room for error with regards to >> the number of fitness evaluations performed. >> >> If the flag is removed, it implies that every time an Entity's solution >> vector is evaluated on the current problem, the number of fitness >> evaluations will be incremented. Is this correct in all circumstances? What >> about dynamic environments, when a same solution vector (that has already >> received a fitness value) needs to be evaluated on the current state of the >> environment, should that count as a unique fitness evaluation? Are there >> any other situations, when you need to calculate a fitness value, where the >> number of evaluations for the algorithm shouldn't be incremented? >> >> If we can standardise the approach so that every evaluation will increase >> the counter, then we know the number of fitness evaluations as a stopping >> condition is correct. And we have decided on the issue from the Entity >> perspective, we can look at it from the Problem perspective. >> >> Regards > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > cilib-devel mailing list > cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-devel > |