On Thu, 16 Oct 2014 00:14:12 +0100, Alfonso Garcia <
barb...@gmail.com>
wrote:
> I'm starting to explore Genetic Algorithms (fascinating subject, by the
> way) using Watchmaker and I've found that my fitness function sometimes
> can return NaN, I can't avoid or prevent that because the fitness
> functions and the data they use are not under my control.
>
> I can easily mask the NaN values and return an extremely bad score value
> in these cases during fitness evaluation, although it seems unnecessary
> because the sort order is correctly preserved and Watchmaker puts NaN at
> the end when sorting fitness results.
>
> However, looking at some of these NaN-fitness elements, it looks
> difficult that crossing over or mutating this subset of population can
> lead to anything useful. So, first question, does Watchmaker has some
> built in means of discarding the lower-scoring items in each evolution
> step? If not, what would be the best place to implement it?
No, there's nothing built-in that would do this for you but it would be
fairly easy to write an EvolutionaryOperator that just discards any
candidates you're no longer interested in.
However, with the way the generational evolution engine is currently
written, it assumes a constant sized population. If you start shrinking
it, it won't replace the discarded candidates to maintain the original
population size and you could eventually end up with the population
becoming extinct.
There are two ways round that. One would be to sub-class or replace
GenerationalEvolutionEngine and make the nextEvolutionStep method take
responsibility for maintaining the the population size somehow.
The other option, if it's no unsuitable for you problem, would be to make
it so that your custom operator always generates a new candidate to
replace any that it discards. This would make it similar to the existing
Replacement operator
(
http://watchmaker.uncommons.org/api/org/uncommons/watchmaker/framework/operators/Replacement.html)
except that you'd be replacing specific individuals rather than picking
them at random.
Dan.
--
Daniel Dyer