You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am am running into some design limitations of the EvolutionEngine classes. I'll try to explain my concrete problem to highlight the issue. My project requires a population of genetic programs to be run on a shared state such that all programs are executed in parallel for a couple thousand iterations before their fitness is known. Shared state access is done between the iterations and needs to be synchronized. The AbstractEvolutionEngine design can not support this, because it implements a different concurrency scheme. A program can not easily suspend the evaluation to let others execute until all have reached the synchronization point to do the shared state access and continue the evaluation. Apart from some ugly hacks to work around the problem a proper solution would require my own EvolutionEngine implementation to support my execution scheme. However, I would end up with a GenerationalSharedStateEvolutionEngine, SteadySharedStateEvolutionEngine and SharedStateEvolutionStrategyEngine. This suggests that the AbstractEvolutionEngine and its subclasses represent a coupling between the functionality needed to produce offspring and the execution scheme.
A more flexible approach that improves reusability would be to implement the different nextEvolutionStepmethods using a strategy pattern rather than the template method pattern. If you agree to this I could implement the necessary changes and send you a pull request.
The text was updated successfully, but these errors were encountered:
Hi Dan,
I am am running into some design limitations of the EvolutionEngine classes. I'll try to explain my concrete problem to highlight the issue. My project requires a population of genetic programs to be run on a shared state such that all programs are executed in parallel for a couple thousand iterations before their fitness is known. Shared state access is done between the iterations and needs to be synchronized. The AbstractEvolutionEngine design can not support this, because it implements a different concurrency scheme. A program can not easily suspend the evaluation to let others execute until all have reached the synchronization point to do the shared state access and continue the evaluation. Apart from some ugly hacks to work around the problem a proper solution would require my own EvolutionEngine implementation to support my execution scheme. However, I would end up with a GenerationalSharedStateEvolutionEngine, SteadySharedStateEvolutionEngine and SharedStateEvolutionStrategyEngine. This suggests that the AbstractEvolutionEngine and its subclasses represent a coupling between the functionality needed to produce offspring and the execution scheme.
A more flexible approach that improves reusability would be to implement the different nextEvolutionStepmethods using a strategy pattern rather than the template method pattern. If you agree to this I could implement the necessary changes and send you a pull request.
The text was updated successfully, but these errors were encountered: