Adaptive Parameter Controller

"Adaptive" parameter tuning is often just a moving average wearing a marketing name - it reacts to recent results but never actually compares candidate values against each other in any principled way, and it has no answer for how much to trust a candidate that has barely been tried yet. This header implements two genuine textbook multi-armed-bandit algorithms instead of a heuristic dressed up as one. UCB1 (AdaptiveSelectArmUcb1) scores each candidate as its observed mean reward plus an exploration bonus of sqrt(2 * ln(TotalPulls) / PullCount) - a bonus that shrinks as an arm is tried more, so under-tried candidates keep getting picked until their own evidence catches up, without the best arm ever being permanently abandoned. Every arm gets one guaranteed pull before the formula runs at all, since ln(0) and division by a zero pull count are both undefined - this is not a special case bolted on, it falls directly out of what "infinite score for an untried arm" means. Epsilon-greedy (AdaptiveSelectArmEpsilonGreedy) explores a uniformly random candidate with probability Epsilon and otherwise exploits whichever candidate currently has the highest mean reward - simpler than UCB1, and a useful comparison point precisely because it explores at a constant rate rather than one that tapers off automatically. Every candidate value passed to AdaptiveInit is clamped into [GuardrailMin, GuardrailMax] before the controller ever runs, and a clamp is reported with Print() when it happens. The bandit cannot explore its way to a value outside a range the operator declared safe, no matter what the reward history suggests - the guardrail is enforced at the one point new arms enter the pool, so nothing downstream needs to re-check it. AdaptiveEnableAuditLog then makes every subsequent AdaptiveUpdate call write one row to a sandbox CSV file - timestamp, arm index, arm value, reward, new running mean, total pulls - so which parameter value was live at any point in a live run is recoverable from disk afterward, not just visible in the Experts tab while the terminal happened to be open. Notes and limitations - ADAPTIVE_MAX_ARMS (16) is a compile-time constant at the top of the header - raise it there if a controller genuinely needs more candidates. - The reward scale is entirely up to the caller (profit in account currency, in R-multiples, a normalised 0..1 score) - UCB1's exploration bonus is on the same numeric scale as the reward, so a reward with very large magnitude will make the bandit behave close to always-exploit (the bonus becomes comparatively tiny) and a very small one will make it behave close to always-explore; normalise rewards to a roughly 0..1 range for the bandit's built-in exploration/exploitation balance to behave as the classic literature describes. - Neither algorithm has any concept of a NON-STATIONARY reward distribution (a candidate whose true quality genuinely drifts over time, e.g. as market volatility regime changes) - both accumulate a simple running mean over the full history, which reacts increasingly slowly to a real change the longer the controller has been running. A regime-aware variant would need a decayed/windowed mean instead, which this header does not provide. - The audit log is append-only sandbox file I/O, same pattern as this catalogue's Logger.mqh - each terminal instance gets its own copy.

Script · MT4 · v1.0 · Free

Tags: Moving Average · MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria