It would be cool to have an "evaluation domain" (a built-in problem domain that RGEP can solve) for graphs and/or finite state machines.

This could end up like Haskell alga, the graph algebra library, or might take another direction. In the paper describing algebraic graphs there is a note at the end about state machines as maps from symbols to graphs that might help.

Move the code that is currently in main into one or more examples to clean up the repo

GA and RGEP should expose a stage version and a "final" version.

This way they can be woven into other algorithms as a unit.

Consider adding PBIL, and perhaps other algorithms.

Currently individuals are vectors of u8. It would be nice to allow any type, and have RGEP specialize to u8.
Most operators should generalize easily, but some may require the more specialized types.

This may be as easy as making Ind = Ind(Vec).

GA and RGEP should be in separate modules, and RGEP should depend on GA, or they both depend on generic functions.

This would make it easier to add other algorithms like PBIL, and should help with variants of RGEP.

Performance testing with immutable structures and single traversal of data.

Either find a way to combine mutation and crossover, or have each operation output a description of what it wants to do (dense update, sparse update, move block) and treat the whole population as a single tree.
Specialize for a GA at first, generate the movements desired, and resolve what needs to happen. Then just go through the population once, doing O(n) splits taking O(ln(n)) time and joins taking O(ln(n)) time.
Do performance testing against the other RGEP implementations to see if the cache behavior helps enough to make this worth it.

What would need to happen to release this library?

1. RGEP function
2. RGEP examples for several domains
3. GA function
4. GA examples
5. Parallel execution- all EA seem to include this
6. Documentation on exposed functions
7. Example of building new algorithms
8. More generic functions (some use u8 explicitly)
9. Some level of benchmarking
10. Documentation for rustdoc

It would be very cool to implement the changes to RGEP in the one referencing paper.

I would have to find the paper again, but the changes should be straightforward.

Add a concept of runners as StageTranformers, taking a stage and returning a stage.

There should at least be a runner for evaluating N times, and for evaluating a predicate on the state.

It looks like some of the types in types.rs have Clone and 'static bounds that seem unnecessary.

Look into removing these.

Look into having the algorithm functions (GA and RGEP) return their state structure instead of just the population. This would supply the user with fitness values as well.

If this is not useful, consider a separate structure to return, perhaps with expressed individuals.

Currently the population type requires an Ind
Generalize to allow more structures to be used.

The genetic operators are currently in the root src directory. They should be separated into an operators directory, perhaps with sub directories for each operator and separate files for each implementation of each operator.

Genetic operators should be able to run in parallel- at least within an operator, if not also in a pipeline.

The easiest way to do this might be to make the operators iterators, and use Rayon.

It seems like the RGEP evaluation domains (tree, arithmetic, decision tree, etc) should be in a separate module to isolate them from the main algorithm code.

The domains that come to mind are:

• simple arithmetic
• decision trees
• symbol trees (sexpr)
• boolean circuits
• sequence manipulation (swap, rot, dup, etc)
• virtual machine instructions

Some genetic operators do not have a stage defined