Discussing the article: "Native Gaussian Process Regression in MQL5: Short-Horizon Price Forecasting with Uncertainty Bands"
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: Native Gaussian Process Regression in MQL5: Short-Horizon Price Forecasting with Uncertainty Bands.
The article rebuilds a Gaussian Process forecaster in native MQL5 around market-state inputs and direct horizon log-return targets. It employs a Matern 3/2 kernel, symmetric Cholesky with adaptive jitter, standardized targets, and a log‑space grid search that avoids state side effects. The EA trades only when az‑score over observed variance clears a threshold and the edge beats the live spread. Calibration is verified in Strategy Tester.
A Gaussian Process is only as good as what you hand it as its input. It's tempting, especially with GPs, to treat the model as a black box that will "figure out" structure on its own - feed it enough points and let the kernel do the work. This article is built around pushing back on that temptation. The engine here forecasts short-horizon price moves on XAUUSD by training on the previous bar's own log return as its feature and the true horizon-ahead log return as its target - both real market-state quantities, not placeholders - and every design choice that follows, from the kernel to the EA's confidence gate, traces back to taking that distinction seriously.
Everything is native MQL5 - no ALGLIB, no external DLL. The GP engine builds its own symmetric kernel matrix, factorizes it with an adaptive-jitter Cholesky decomposition, and keeps the model's uncertainty about the underlying trend (latent variance) separate from its uncertainty about a realized future price (observed variance, which adds the noise term back in). The hyperparameter search runs in log-space and never mutates the object's fitted state mid-search, so a live refit can't be left half-updated if a candidate combination fails partway through.
One honest note up front, because it matters for how to read section 11: a Gaussian Process fit on a single lag-return feature is, at best, a diagnostic worth checking - whether it carries any consistent predictive information for XAUUSD M5 is exactly the open empirical question a calibration check is for, not something the feature definition proves on its own. Section 11 sets out that check in full: run the EA with InpLogCsv on, let it log one row per forecast, and compare what fraction of realized outcomes land inside the model's own stated 1-sigma and 2-sigma bands against the 68%/95% a correctly-specified Gaussian predictive distribution implies. That methodology is concrete and already in the code; the actual coverage figures still depend on running it, and section 11 is explicit about which parts are measured and which are not yet filled in.
Author: Adewumi Babatunde Gbadebo