Constraint Penalty Framework

A hand-rolled optimiser - grid search, hill-climbing, simulated annealing - usually gets box bounds bolted on by clamping the candidate before it is evaluated. That works fine for a single-parameter bound, but breaks down the moment a constraint couples two parameters together, such as "stop distance plus spread buffer must not exceed 40 pips combined" - there is no single-parameter clamp that fixes a violated linear combination like that. The standard general fix is a penalty: add a term to the objective proportional to how far outside the feasible region a candidate sits, so the optimiser is pushed back toward feasibility by its own search dynamics rather than being hard-clamped every step, which can trap a hill-climber against a constraint boundary and stall its progress entirely. This header offers both tools. RepairClampBox is the cheap, exact fix for box bounds alone - use it whenever no parameter interacts with another. PenaltyBoxViolation and PenaltyLinearViolation (plus the multi-constraint variant) compute a smooth, squared-distance-past-the-boundary penalty for box bounds and for one or more linear inequality constraints of the form sum(coefficient * parameter) <= right-hand-side, and AugmentedObjective folds a raw score and a total penalty into the single number an optimiser should actually minimise. What this header deliberately does NOT attempt is a general linear- constraint repair - projecting a candidate exactly onto a violated linear inequality's boundary is a small linear-algebra problem in its own right, out of scope for a lightweight wrapper. The penalty route above is the answer for that case, not silently pretended-away. Notes and limitations - RepairClampBox is an exact fix for box bounds only - it has no concept of a linear constraint coupling two parameters, and does not attempt one. - The linear-constraint penalty functions handle "<=" inequalities. A ">=" constraint can be expressed by negating both the coefficients and the right-hand side before calling; an equality constraint can be approximated with two opposing "<=" penalties, but neither transform is done automatically - the caller must apply it. - PenaltyLinearViolationMulti expects its coefficients flattened into one array (row i occupying coeffFlat[i*nParams .. i*nParams+nParams-1]) because MQL4 has no convenient dynamic 2D array type - get the row stride (nParams) wrong and the penalty is silently computed against the wrong coefficients rather than raising an error. - The demo's own optimiser (a plain random local search) is illustrative only, not a general-purpose optimiser in its own right - the point of the demo is the penalty wrapper around it, not the search algorithm.

Script · MT5 · v1.0 · Free

Tags: Grid · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria