Discussing the article: "Beyond the Clock (Part 2): Building Runs Bars in MQL5"
Nice choice for the article tagline ;)
(Beyond GARCH .... Beyond The Clock)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Beyond the Clock (Part 2): Building Runs Bars in MQL5.
We implement tick-, volume-, and dollar-runs bars in Python and MQL5 and align them with the existing bar‑building framework. The article details the dual‑accumulator update, offline calibration with per‑side seeds, state persistence for EAs, and parity verification to match Python and MQL5 outputs. Runs bars expose one‑sided bursts that net imbalance can hide, improving coverage during quiet sessions and for mean‑reversion models.
The previous article implemented all ten bar types from Chapter 1 of López de Prado's Advances in Financial Machine Learning, including tick, volume, and dollar imbalance bars. One family was left with a briefer treatment than the others: runs bars. This article completes the picture.
Runs bars are a close relative of imbalance bars. An imbalance bar closes when the cumulative signed metric — summing over all ticks, each weighted by its direction — exceeds a threshold. A runs bar closes when the cumulative metric computed from ticks of the dominant side alone exceeds a threshold. The distinction matters: imbalance bars respond to net directional pressure, which can be masked when buy and sell volume are large and roughly equal; runs bars respond to the raw magnitude of whichever side is currently dominant, making them sensitive to bursts of one-sided activity even when the opposing side is also active.
The implementation follows the same architecture as the previous article: Python extends afml.data_structures with three runs-bar types behind make_bars(), while MQL5 adds CRunsBar with tick-by-tick logic and the same persistence interface. Parity checks confirm identical bar sequences given the same tick stream.
This article addresses four implementation details. First, it explains how the run and imbalance recurrences differ and why that matters in code. Second, it covers runs-bar initialization and extends target_timeframe calibration accordingly. Third, it specifies the additional state required for persistence across EA restarts. Fourth, it outlines when runs bars differ materially from imbalance bars.
Author: Patrick Murimi Njoroge