The classic forum is still available at https://pipflow.com/oldforum/index.php.
Forum Sign in Register

Genetic Programming for Trading: Evolving Rules, Not Just Parameters

Started by Support 6 days ago · 0 replies RSS

Genetic Programming for Trading: Evolving Rules, Not Just Parameters

Most traders who reach for "genetic algorithms" are really using them to tune the numbers in a strategy they already wrote — the lookback, the stop distance, the threshold. That is genetic optimization, and it is useful. Genetic programming (GP) is the more ambitious cousin: instead of evolving the parameters of a fixed rule, it evolves the rule itself. This post is about what that buys you, and why it bites back harder than anything else in this corner of the field.

Parameters vs structure
A genetic algorithm searches a fixed-shape space: "find the best 5 numbers." Genetic programming searches the space of programs — typically expression trees. A candidate is a tree like ( (EMA(20) > EMA(50)) AND (RSI(14) < 30) ), and the algorithm mutates and recombines whole branches. The output is not a parameter set; it is a brand-new entry/exit condition you never thought to write.

How the evolution works
  • Building blocks. You define the alphabet: indicators (EMA, RSI, ATR, price), operators (>, <, AND, OR, +, -), and constants. GP composes these into trees.
  • Fitness. Each tree is compiled into a signal and backtested. Its fitness is your objective — but please, not raw return (see below).
  • Crossover. Swap a subtree from one rule with a subtree from another. Two mediocre rules can produce a strong child, or nonsense.
  • Mutation. Randomly replace a node or branch to keep diversity and escape local optima.
  • Selection. Keep the fitter trees, breed the next generation, repeat for N generations.


Fitness is where strategies live or die
If you set fitness to "highest backtest return," GP will hand you a baroque, 40-node monster that perfectly explains the past and predicts nothing. Defend yourself:
  • Multi-objective. Optimize return and drawdown and trade count simultaneously — an approach like NSGA-II gives you a Pareto front of trade-offs instead of one over-tuned winner.
  • Parsimony pressure. Penalize tree size. A short, readable rule that generalizes beats a sprawling one that memorizes.
  • Out-of-sample fitness. Evaluate fitness on data the evolution does not breed on, and reserve a final untouched set you look at exactly once.


The bloat and overfitting problem
GP overfits more aggressively than almost any other method because the search space is effectively infinite — there is always a more elaborate tree that fits the noise a little better. Two symptoms to watch: bloat (trees grow huge for tiny fitness gains) and brittleness (the evolved rule collapses the moment the regime shifts). If your champion rule needs eight nested conditions to work, it almost certainly does not work.

A sane workflow
  • Keep the building-block set small and economically meaningful. Garbage primitives evolve garbage rules.
  • Run several independent evolutions with different seeds; only trust rules that show up repeatedly in different forms.
  • Validate every survivor with walk-forward analysis before it touches real money — evolution finds the past; walk-forward tests the future.


Bottom line
Genetic programming is one of the few tools that can genuinely surprise you with a rule you would not have written by hand. That same creativity is exactly why it overfits so readily. Treat it as a hypothesis generator, not an oracle: let it propose, then judge its proposals with the same brutal out-of-sample discipline you would apply to your own ideas.

Have you tried evolving rules rather than parameters? What primitives did you give it, and did anything survive contact with live data? Tell us below.

Sign in to reply.