Simulated Annealing Optimiser

Plain hill-climbing - always move to a better neighbour, never a worse one - gets permanently stuck the moment it reaches a local optimum. On a rough, multi-humped surface, which is what most parameter-optimisation landscapes actually look like, that is most of the search space, not a rare edge case. Simulated annealing sometimes accepts a WORSE move, with a probability that starts high and shrinks as a "temperature" parameter cools - the Metropolis criterion, exp(-delta/T). Early on, while T is high, this lets the search escape a local optimum's basin entirely; as T cools toward zero it settles into the same kind of exploitation plain hill-climbing would do, just starting from a much better-explored position. This header implements the real thing: a geometric cooling schedule (temperature multiplied by a cooling rate after a fixed number of proposals at each level), genuine Metropolis acceptance of worse moves, and optional independent random restarts that hedge against any single run settling into a mediocre basin by bad luck. The objective function is supplied as a function pointer (an n-dimensional array in, a single double to minimise out), so this header works on any parameter-search problem the caller defines - not tied to any specific trading concept. The demo minimises a 2D Rastrigin function (global minimum 0.0 at the origin, riddled with regularly-spaced local dips) and contrasts a plain greedy hill-climb - which gets trapped in the nearest dip to its starting corner - against simulated annealing run from the same starting corner. Notes and limitations - To MAXIMISE an objective instead of minimising it, hand in a wrapper function that returns the negation of the value you actually want maximised - the optimiser core only ever minimises. - Like any stochastic global search, this is not guaranteed to find the true global optimum on every run, only to search far more robustly than a plain local hill-climb. More restarts and a slower cooling rate (a value closer to 1.0, e.g. 0.97) trade runtime for a better chance of finding the true optimum, and are worth increasing on a hard problem. - Neighbour proposals are isotropic (the same relative step size in every dimension, scaled by each dimension's own range) - a problem with wildly different natural scales per dimension should have its bounds/units chosen so a step of similar RELATIVE size makes sense in every dimension. - MathSrand() controls the whole run's reproducibility, since MQL4's MathRand() is one shared global stream - call it before SaOptimise for a repeatable result, as the demo does.

Script · MT5 · v1.0 · Free

Tags: MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria