Hodrick Prescott Filter

A moving average trades lag for smoothness along a single dial: a longer period is smoother and slower, a shorter one is faster and noisier, and there is no principled way to say which trade-off is "correct" for a given series. The Hodrick-Prescott filter (Hodrick & Prescott 1997) instead solves an explicit optimisation problem: find the trend line that minimises squared deviation from price, plus lambda times the sum of squared second differences of the trend itself. The first term keeps the trend honest to price; the second penalises the trend's own curvature. Lambda is the one dial, and it has a direct, published meaning - units of curvature penalty per unit of fit error - rather than being a lookback window dressed up as something else. This is the single most cited decomposition in macroeconomic research, applied here to a price series instead of GDP, and it has essentially no presence on MetaTrader CodeBase. The exact optimum is the solution to a pentadiagonal linear system (five nonzero diagonals, from the second-difference penalty). Most from-scratch implementations hand-derive a banded LU factorisation for this, which is easy to get subtly wrong at the four boundary rows where the curvature penalty has fewer terms to sum. This library instead solves the system with Gauss-Seidel iteration, which is mathematically guaranteed to converge here because the HP penalty matrix (identity plus lambda times a positive semi-definite curvature matrix) is symmetric positive definite, and Gauss-Seidel converges for any SPD matrix regardless of diagonal dominance. Fewer places for a boundary-index bug to hide, same exact answer at convergence. HpFilterBatch is the textbook two-sided filter: every point's trend value depends on the whole series, including bars that come after it. That is fine for historical analysis but means the most recent bar's trend value keeps shifting as new bars arrive - a classic and often-unstated limitation of running any two-sided smoother "live". HpRollingUpdate is the bounded, live-safe answer: it keeps a fixed-size trailing window and re-solves the (small) pentadiagonal system for just that window on every new bar, returning a one-sided "nowcast" trend at the newest point. Cost per update is O(window length) regardless of how long the chart's history is, which is what makes it safe to call every bar rather than re-solving the whole visible chart on every tick. Notes and limitations - Lambda has no universal "correct" value for intraday price series the way it does for quarterly GDP - the 1600/14400 conventions come from macro research on data sampled at those frequencies. Backtest a lambda against the timeframe and instrument you actually intend to use. - The rolling variant's estimate at the newest bar is a one-sided nowcast, not the same number the batch filter would give that bar once more history exists after it - this is an inherent property of any two-sided smoother's live edge, not a defect specific to this implementation. The demo's cross-check section shows the rolling and batch answers agreeing on the SAME trailing window, which is the correct comparison to make. - Gauss-Seidel is iterative: HpFilterBatch runs up to maxIterations sweeps and stops early once the largest per-bar change drops below tolerance. For a very large lambda on a long series this can take more iterations to settle; the defaults are generous for typical chart-length windows. - This is a smoothing/decomposition tool, not a trading signal generator. It places no trades and issues no buy/sell decision on its own.

Script · MT5 · v1.0 · Free

Tags: Moving Average · Trend · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria