evolutionary_loop.hpp File Reference

The shared six-step evolutionary-loop skeleton (evaluate -> select parents -> vary via crossover/mutation -> evaluate offspring -> survivor-select -> loop), generic over which survivor-selection policy (survivor_selection.hpp) and which offspring-production recipe (selection + crossover + mutation, composed by the caller) is used. More...

#include <future>
#include <utility>
#include <vector>
#include "pulsatrix/data_thread_pool.hpp"
#include "pulsatrix/individual.hpp"

Include dependency graph for evolutionary_loop.hpp:

Go to the source code of this file.

Namespaces
namespace	pulsatrix

Functions
template<typename Genotype , typename FitnessT , typename FitnessFn >
void	pulsatrix::EvaluatePopulation (std::vector< Individual< Genotype, FitnessT > > &population, FitnessFn &fitness_fn, DataThreadPool *thread_pool)
	Evaluates (or re-evaluates) every individual's fitness in place via fitness_fn.
template<typename Genotype , typename FitnessT , typename FitnessFn , typename OffspringFn , typename SurvivorFn >
std::vector< Individual< Genotype, FitnessT > >	pulsatrix::RunEvolutionaryLoop (std::vector< Individual< Genotype, FitnessT > > population, size_t num_generations, size_t lambda_size, FitnessFn fitness_fn, OffspringFn produce_offspring_genotype, SurvivorFn survivor_selector, DataThreadPool *thread_pool=nullptr)
	Runs num_generations of the shared evolutionary-loop skeleton: evaluate -> produce lambda_size offspring (via produce_offspring_genotype, called once per offspring) -> evaluate offspring -> survivor-select mu individuals for the next generation.

Detailed Description

The shared six-step evolutionary-loop skeleton (evaluate -> select parents -> vary via crossover/mutation -> evaluate offspring -> survivor-select -> loop), generic over which survivor-selection policy (survivor_selection.hpp) and which offspring-production recipe (selection + crossover + mutation, composed by the caller) is used.

Note

Deliberately does NOT bundle a specific selection/crossover/mutation composition into this loop – how a caller composes those (which selection operator, which crossover, whether/how to mutate) is left to the caller's own offspring-production callable, the same "wire manually, don't build a generic training abstraction" discipline this project's RL campaign already established for its own training loops. What genuinely is shared across generational/(mu+lambda)/(mu,lambda) – the loop shape itself and fitness evaluation – is written once, here.

Single-node thread-pool parallel fitness evaluation reuses DataThreadPool (data_thread_pool.hpp, built for the data-pipeline campaign's DataLoader) rather than a second thread pool – found by this campaign's own Mission 0 activation recon.