Discussing the article: "Beyond the Clock (Part 1): Building Activity and Imbalance Bars in Python and MQL5"

New comment
 

Check out the new article: Beyond the Clock (Part 1): Building Activity and Imbalance Bars in Python and MQL5.

The article replaces clock-based sampling with López de Prado's alternative bar types and provides two aligned implementations: a unified Python module for batch tick histories and an object‑oriented MQL5 library for live EAs. It covers Parquet/Dask infrastructure, data cleaning, and a single API. Practical issues are solved explicitly: zero‑tick time‑bar filtering, imbalance threshold initialization, EWM state persistence, and parity between Python and MQL5 outputs.

A model trained on one-minute bars inherits an assumption that has nothing to do with the market: that every 60-second window contains the same amount of information. It does not. A minute during the London open may carry hundreds of ticks and a directional move; a minute at 03:00 UTC on a Sunday may carry three ticks and zero signal. Treating both as equivalent observations injects heteroscedasticity at the data layer, before any feature is computed.

Chapter 1 of López de Prado's Advances in Financial Machine Learning replaces clock-based sampling with activity-based and intent-based alternatives. This article implements all ten bar types from that chapter in two implementations: a unified Python module (afml.data_structures.bars) for batch processing of multi-year tick histories, and an object-oriented MQL5 library for live tick-by-tick construction inside an Expert Advisor.

Four production problems in the pipeline are addressed explicitly: loading multi-year tick data without exceeding memory (partitioned Parquet storage read via Dask), cleaning broker-feed artifacts that corrupt bar construction (zero spreads, duplicate timestamps, NaT indices), calibrating the adaptive threshold for imbalance bars automatically so the first bar does not bias the EWM history, and persisting the EWM tracker across EA restarts so the threshold does not reset mid-session. A short parity test at the end verifies that the two implementations, fed the same tick stream, produce identical bars.

Beyond the Clock (Part 1): Building Activity and Imbalance Bars in Python and MQL5

Author: Patrick Murimi Njoroge

 

So, you're inventing equal volume bars, range bars, renko etc non-time charts?

It's strage to read things like this:

source of raw tick data via copy_rates_from_pos()

because this function returns quotes/bars, not ticks.

 
Stanislav Korotky #:

So, you're inventing equal volume bars, range bars, renko etc non-time charts?

It's strage to read things like this:

because this function returns quotes/bars, not ticks.

Equal volume bars, range bars, and Renko are threshold-based chart types — they trigger a new bar when price moves a fixed distance or a fixed volume is reached. The bar types in this article are information-theoretic: they sample a new bar when the market has produced a defined quantity of activity (ticks, volume, or dollar turnover). The distinction matters because the threshold itself adapts to recent activity rather than being set once. Imbalance bars go further — they condition on directional order-flow imbalance rather than total activity, so bars cluster around periods of one-sided pressure. These are López de Prado's constructions from AFML Chapter 2; the article implements and ports them to MQL5, it does not originate them.

You are correct — CopyRatesFromPos() returns OHLCV bars, not raw ticks. The phrase "source of raw tick data" in that section is a labeling error; the function is used to retrieve the bar series that feeds the bar-construction input. I have corrected the article text. Thank you for catching it.
New comment