Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting reusable chromosomes #33

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Conversation

wjladams
Copy link

In my particular usage of the watchmaker library my chromosomes are very large. Recreating them over and over was hurting performance badly. So I added a "Releasable" interface and made my chromosomes implement that. When GenerationalEvolutionEngine is done with a chromosome I added a couple of lines of code to check if the chromosome implements the Releasable interface, and if so it calls chromosome.release() prior to releasing it from the population.
This allows me to recirculate that object and avoid destroy/recreating objects. This change sped up my algorithm by a factor of 10+.
The majority of the code in this pull request is to add a unit test to make sure releasing is actually working, in addition to adding a simple ReleasablePool implementation.

wjladams and others added 13 commits November 27, 2018 13:19
Previous version 1.2.2 will no longer compile (it requires
jfreechart 1.0.8 which no longer exists in the maven repo).
Now when the GenerationalEvolutionEngine is done with a chromosome,
and the chromosome implements the Releasable interface, it calls
chromosome.release().  This effectively allows that chromosome to
be reused if that behavior is desired.
See HelloWorldGeneratorV2 or HelloWorldGneratorV2Test for this working.
Problem was waiting for UI to sync, a few extra robot.waitForIdle()
did the trick.
Also updating programmers for this branch to just me.  Not sure
if that is the correct protocol, but at the same time I don't want
to volunteer others to be contributors to my branch.
A termination validator that takes into account:
   1. A minimum generation count, before even considering termination
   2. A maximum generation count, once reached we consider it terminated
   3. The history of the fitness function for each generation
If we are between min/max number of generations, we look at the history
of fitness function values for timesMustBeClose before the current
generation.  If each successive value is within closeEnough of the
previous generation for timesMustBeClose, we consider it converged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant