Filter Response Analyzer

Most custom smoothing filters used in trading (a modified moving average, a hand-tuned digital filter, a cascade of several stages) ship with no real answer to "how much does this actually lag price" or "how much of a genuine move does this actually let through" - only a vague sense from looking at a chart. This library answers both questions properly by running the filter against known test signals and measuring the result: a step response gives steady-state gain, rise time, overshoot and settling time (the standard control-theory vocabulary for describing how a system reacts to a sudden change); a sine response at a specific period gives gain and phase lag AT THAT FREQUENCY specifically, via a single- frequency synchronous (Goertzel-style) correlation against the known test frequency - the lightweight, FFT-free way to read one frequency bin accurately. DESIGN CHOICE - no function pointers. MQL4 has no callable function- reference type, so this library cannot "run the caller's filter" the way a language with function pointers or first-class functions would. Instead every measurement function takes the filter's OUTPUT as a plain array, already computed by the caller by running their filter over the matching FraGenerateStep/FraGenerateSine test-input array externally, before calling in here. This is not a workaround bolted onto a design that wanted function pointers - it is the natural shape for MQL4: the caller already has to run their own filter every bar in their EA or indicator, so handing this library the resulting series costs nothing extra and needs no unsafe pointer emulation to fake what the language does not have. Notes and limitations - No function pointers, by design (see the design-choice note above) - the filter under test must already have been run externally, and its output array handed to the measurement functions alongside the matching FraGenerateStep/FraGenerateSine input array. - FraMeasureSineResponse's phaseLagBars has an inherent ambiguity: phase repeats every full cycle, so a filter that delays by (periodBars + k) bars cannot be told apart from one delaying by k bars, purely from a single-frequency phase reading. The function always returns the smallest-magnitude lag consistent with the measurement, in (-periodBars/2, periodBars/2] - correct for most simple smoothing filters at a reasonable test period, but corroborate with FraMeasureStepResponse's settling time for a heavily-lagging filter. - FraMeasureSineResponse needs a warmup window covering several periods before it starts correlating (so both the filter's own startup transient AND enough full cycles for the sin/cos orthogonality approximation to hold have passed) - too short a warmup or too few total periods in the test window gives an inaccurate reading rather than an outright failure, so use a generous total series length (the demo uses at least 4 periods of warmup and hundreds of bars total). - Step-response settling time is measured against the END of whatever series was supplied, not a true infinite-horizon settling time - supply a series long enough that the filter has clearly reached steady state well before the end, or the reported settling time will understate how long the filter actually takes.

Script · MT5 · v1.0 · Free

Tags: Moving Average · Buy/Sell Arrows · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria