SigmaX
commented
3 years ago Thought: Steady-state evolution is an operator.
What makes steady-state different from generational is that it separates the notion of "updating a population" from "running individuals through a reproductive pipeline." You have this reproductive process kind of out to the side, and it reaches in to pull and insert individuals into this persistent population over on the other side.
That's why we currently have separate metaheuristics for generation_ea and steady-state EAs.
But, since steady-state reproduction is so different, why don't we think of it as separate from the population pipeline? Or as its own sub-pipeline? We could just plug a "steady-state operator" into a generational pipeline something like this:
ea = generational_ea(generations=100,pop_size=pop_size,
problem=problem,
representation=...,
# Operator pipeline
pipeline=[
ops.steady_state_step(
reproduction_pipeline=[
ops.tournament_selection,
ops.clone,
mutate_binomial(std=1.5, bounds=[problem.bounds]*l,
expected_num_mutations=1)
]),
contestant_selector=ops.random_selection,
evaluator=...
),
# Some visualization probes so we can watch what happens
probe.PlotTrajectoryProbe(xlim=problem.bounds, ylim=problem.bounds,
contours=problem),
probe.PopulationPlotProbe(),
probe.FitnessStatsCSVProbe(stream=sys.stdout)
]
)This gives us a loosely-coupled view of steady-state EAs as a kind of generational EA that has a nested operator. The operator takes a population, does something to it, and returns the modified population.
One advantage is that it's easy to toss population-level probes onto the end of the pipeline.
The downside is it's a bit tricky to introduce people to: having a reproduction_pipelien inside another pipeline operator may be confusing and steepen the learning curve.
markcoletti
We've got nice pluggable operators for generational evolution, but our support for steady-state mechanisms is a little rough around the edges.
Specifically, steady-state algorithms make use of "insertion" operators. These typically
For step (2), it would be really nice if we could use the same selection operators we use for everything else (ex.
ops.tournament_selection,ops.random_selection, etc.). But these operators return individuals, and for step (3) we need to know the index of the selected individual so we can replace it with the new one.We've handled this two different ways so far:
distributed.asynchronousmodule, we wrote custom insertion functions to that implicitly re-implement hard-coded selection methods as needed, but based on indices.In the
ops.migrate()function, we accepted a standard selection operator as acontestant_selectorargument, and then used thepopulation.remove()list operator to delete losing contests. This searches the population by value, which is problematic (not to mention slow):It would be nice to have the best of both worlds.
One solution I can think of it having selection operators take an optional argument of a mutable list that they could populate with the indices of the selected individuals. That's a little ugly, but would give us a way to get index information out of them when we need it, but ignore it when we don't.