Moving Average Variants

iMA() already covers simple, exponential, linear-weighted and smoothed (Wilder) averages well on both platforms, so this library does not reimplement any of them. What it adds are four variants that solve the lag problem a plain moving average always has - the average necessarily reacts to a trend change some bars after it happens, by construction. HullMA (Alan Hull's construction) computes two weighted averages at different lengths, takes twice the shorter minus the longer, and smooths the result again - the combination cancels a large fraction of the lag a plain WMA of the same period carries. ZeroLagEMA compensates BEFORE smoothing: it adds back the difference between the current price and the price from half a period ago, then runs an ordinary EMA over that adjusted series, cancelling most of the delay an EMA introduces. Both trade some extra wiggle in ranging conditions for reacting sooner at a genuine reversal - the demo's synthetic series has a sharp trend reversal partway through specifically so that trade-off is visible in the printed numbers, not just asserted in prose. TriangularMA is the opposite trade - an SMA of an SMA, which weights the middle of the window most heavily and produces a smoother, laggier line than a plain SMA of the same period. Useful as a slow baseline to compare a faster average against. VolumeWeightedMA weights each bar's contribution by its volume rather than its position in the window, so a high-volume bar (a real move) pulls the average toward it more than a thin, low-volume bar does. On both platforms this normally means tick volume, since real volume is rarely available from a retail broker - the function works with whatever long array you pass, and the demo's synthetic volume rises around its reversal bar the way real volume typically does at a turning point. All four are plain array functions with no dependency on OnCalculate, indicator buffers, or a chart being open - call them from a script, an EA, or a backtest exactly as shown in the demo, on either platform. None of them touches iMA, a handle, or CopyBuffer at all: the whole library operates on a caller-supplied plain double array, which is why it needed no structural change for the MQL5 port - only the header comment differs meaningfully. Notes and limitations - Arrays are treated as plain, chronologically ordered data (index 0 = oldest). A timeseries array - MQL4's Close[]/High[]/Low[] or an MQL5 CopyClose()/CopyBuffer() result, both index 0 = newest bar by default - is the opposite convention. Reverse it first (ArraySetAsSeries(arr, false), or copy manually) or the window each function looks back over will be the wrong end of the series. - Every output array is the same length as the input. Indices without enough history are filled with MA_NO_VALUE, not 0.0 - a real price could plausibly be near zero on some instruments, so a sentinel that cannot be mistaken for a real value is used instead. Always check against it before reading an entry near the start of the array. - HullMA and ZeroLagEMA reduce lag, they do not eliminate it, and both can overshoot on a sharp, brief spike that reverses immediately - neither is a substitute for a proper reversal filter if false signals matter to the strategy. - VolumeWeightedMA on both platforms almost always means tick volume, not traded volume - it is a count of price changes, not executed size. Treat it as a proxy for activity, not a true volume-weighted price the way it would be on an exchange with real trade prints. On MQL5, feed it the array from iTickVolume/CopyTickVolume, not the deprecated iVolume/CopyVolume path.

Script · MT5 · v1.0 · Free

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

MQL4 & MQL5 scripts · PolyMaria