One space optimization for evolutionary algorithms is to reuse the space of dead genomes to reduce (even eliminate) allocations during the main loop. In the current API, Evo encourages using a finalizer to recycle the memory. To make this as easy as possible, Evo allows the user to define a Close method that gets registered as a finalizer. In the examples, the Close methods use a sync.Pool to handle the memory recycling.

There are a couple problems here. First, finalizers are not guaranteed to run. This means the Close method has no real meaning in the API because Evo may ignore it. If the genome MUST cleanup resources, the user is forced to do this without relying on the Close method. Second, a sync.Pool frees the recycled but unused memory at each GC cycle. This limits the extent to which the optimization is valuable.

Addressing the first problem, we could remove the Close method from the Population interface. This should have minimal backwards-compatibility implications since the method is not guaranteed to be called in the first place. A difficulty arises when we use a pool selector for replacement in that the user does not know when a genome is being discarded. We could incorporate the cleanup into a pool selector, and this may involve some kind of generic selector.

As for the second problem, we can simply introduce our own long-lived free list type. This should be trivial relative to the sync.Pool type since we don't need to interact with the runtime.

As started in #12, I'm revamping the core API to be easier to extend. As part of this, I'm going to rethink the way the Close hook works, per #11.

TODO

• [x] Update the interfaces
• [x] Update the concrete populations
  • [x] generational
  • [x] graph
• [x] Add migration functions
• [x] Rework (Genome).Close
• [x] Update the examples
  • [x] ackley
  • [x] queens
  • [x] tsp
• [x] Cleanup (remove dead code, squash commits, etc.)

The Genome interface wraps the representation of the object being optimized. The inner loop of the GA needs to know of the representation, but it is not itself a property of the representation. Thus the Evolve method should be split from the Genome interface into a new type and provided to the population dynamically.

eg, something like this:

// A Genome is an instance of the object being optimized.
type Genome interface{
    Fitness() float64
}

// An EvolveFn is called in parallel for each member of a population and returns a replacement.
type EvolveFn func(current Genome, suitors []Genome) Genome

// A Population manages the evolution of a population of genomes.
type Population interface{
    Evolve(seed []Genome, loop EvolveFn)
    // ...
}

Currently, the graph population type is public to make the SetDelay method available. If SetDelay were required by all populations, then the graph population could be a private type.

• [x] Add SetDelay to the population interface
• [x] Implement SetDelay on the generational population
• [x] Make the graph population private
• [x] Implement Population.Start

The graph population may close a genome before it's done using it.

Genomes are closed when the inner-loop of the containing node is complete and a new genome is set to replace the contents. However, the genome may be used by neighboring nodes in their inner-loop. To fix this, we need to keep up with the references to the genome and delay closing until the reference count is 0.

The work around is to not rely on the close method of genomes it you rely on the graph population. This prohibits certain optimizations, like recycling genomes. Fixing this is high priority.

Adds the missing pieces for simple evolution strategies.

• [x] Helpers for real valued vectors (naive)
• [x] Coordinated elite replacement
• [x] Ackley function as an ES example

The same helpers should work for parent and replacement selection. Non-trivial replacement selections require synchronizing many concurrent evolve loops.

The Cross method does more than just crossover: it handles the entire inner-loop body. It would more appropriately be named Evolve. This requires updating both the code and documentation.

Hi,

I love your project!!

I changed the stats package to a faster single-pass calculation. sumsq is now truly a sum of squares and mean was replaced with sum. This allows for a much faster Put method which is where most time is spent. The determination of min and max is faster too as there is not overhead call to functions in the math package.

Unit tests pass as they are. A local benchmark showed original package of ~18ns/op and new package is ~8ns/op. Every bit helps, especially in genetic algorithms.