Re: [cilib-devel] Fitness evaluation counting

[Theuns C. <the...@gm...>]

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
>