The Core Engine of the Indicator
The core engine of the indicator is a mathematical fitting algorithm that uses cubic spline interpolation (Cubic Spline Interpolation). Its purpose is not to calculate an average, like traditional indicators (e.g., moving average), but to create a smooth, dynamic curve that best represents the trajectory and acceleration underlying the most recent price points. Inside the GetCachedSplineValue function: CAlglib::Spline1DFitCubicWC(...)
This is not a simple addition or multiplication. This function call launches a complex, iterative numerical algorithm that:
Builds a system of matrix equations.
Solves this system to find dozens or even hundreds of coefficients (the coefficients of the spline’s polynomial segments).
Ensures that the resulting curve is “smooth” and satisfies mathematical conditions (derivatives are continuous).
This is computationally comparable to a single step in complex physics simulations or 3D graphics rendering — it requires significant processing power.
Think of it like this:
A moving average is like a rigid ruler that only shows the central position of prices.
This spline engine is like a flexible, bendable ruler that you shape to fit as closely as possible to the pattern formed by the price points.
The result is an organic curve that better represents the "true" movement of price.
How the Engine Works Step by Step (GetCachedSplineValue Function)
1. Data Collection and Adaptation
The engine does not use a fixed period length. It first calculates a dynamic period using the CalculateAdaptivePeriod function.
If market volatility (based on ATR) is high, the period shortens, making the indicator more sensitive.
If volatility is low, the period lengthens, making it smoother.
After this, it collects a defined number of historical closing prices (close[]) for computation.
2. Data Normalization
Price values (e.g., 1.07123, 1.07543) are mathematically heavy to handle.
Therefore, the engine “normalizes” the data. It finds the highest and lowest prices in the collected dataset.
Each price point is then converted into a relative value between 0–100.
This makes the calculation more stable and independent of the instrument’s price level.
3. Mathematical Fitting (The Spline Fit)
This is the core operation. The engine feeds the normalized price points into the external ALGLIB library, specifically into the function CAlglib::Spline1DFitCubicWC.
This function performs heavy mathematical work: it calculates a cubic polynomial (third-degree curve) that passes through the given points as “smoothly” as possible.
The user-defined parameter InpFitSmoothness (Spline Fit Smoothness) controls the “tightness” of the fit:
A smaller value means a smoother, more general curve.
A larger value forces the curve to follow price points more closely.
4. Value Extraction from the Curve
Once the mathematical model (spline) is created, the engine uses the CAlglib::Spline1DDiff function to ask the model:
“What is your value (s), your first derivative i.e., velocity (ds), and your second derivative i.e., acceleration (d2s) at the very latest point?”
The main curve of this indicator (PriceBuffer, the blue line) is exactly this returned value s (the spline value). It is the final output of the engine, which is then plotted on the chart.
In Summary
The core engine of the indicator does not follow price directly. Instead, it first builds a mathematical model (a flexible curve) of it, and then reads the current value from this model. This process filters out market noise and reveals the fundamental dynamics of price movement, enabling more reliable calculation of speed and acceleration at later stages.
Additional cache logic ensures that this heavy computation is performed only once for each candle. The spline fitting calculation performed inside the indicator’s core engine is an extremely heavy operation.
Cause-and-Effect in Detail
What exactly is so slow?
The source of the slowness is a single function call inside the GetCachedSplineValue function:
CAlglib::Spline1DFitCubicWC(...)
This is not a simple addition or multiplication. This function call launches a complex, iterative numerical algorithm that:
Builds a system of matrix equations.
Solves this system to find dozens or even hundreds of coefficients (coefficients of spline polynomial segments).
Ensures that the resulting curve is “smooth” and satisfies mathematical conditions (derivatives are continuous).
This is computationally comparable to a step in complex physics simulations or 3D graphics rendering — it requires significant processing power.
The Chain Reaction of Heaviness
When you change any input parameter or add the indicator to a chart, the following chain reaction occurs:
Full Recalculation
MetaTrader considers that the indicator must be fully reinitialized.
It calls the OnInit() function and then the OnCalculate() function, with prev_calculated equal to zero.
Massive Loop
Since prev_calculated is zero, the main loop of OnCalculate (for(int i = limit; i >= 0; i--)) must go through every single candle in the entire chart history.
For example, if your chart has 5000 candles, this loop executes 5000 times. (I added inputgroup where you can limit number of iterative operation candles)
Heavy Call Stack
Now, combine these two things. Here’s what happens:
On each of those candle iterations...
...the GetCachedSplineValue function is called.
...and inside it, the extremely heavy Spline1DFitCubicWC calculation is performed again.
The result: the indicator doesn’t perform one heavy calculation, but instead performs each candle consecutive heavy calculations immediately on startup. This is why the process easily takes 5–10 seconds and why the interface “freezes” (the indicator window goes blank) during this time.
Why doesn’t the cache help at the start?
The code has two cache mechanisms, but neither can prevent this initial slowdown:
Global Cache (g_spline_cache)
This is a good optimization, but in the OnCalculate function there is the line:
if(prev_calculated == 0) { g_cache_size = 0; }.
This means that when the indicator is reloaded, the cache is completely cleared.
It therefore cannot speed up the first, heaviest calculation. It only helps afterward, when new candles arrive one at a time.
Function-internal Static Cache
The static-variable-based cache inside the GetCachedSplineValue function also resets whenever the indicator is reloaded (e.g., when inputs are changed).
So it too is unavailable during the initial loading.
Final Summary
The slowdown is not a bug, but a direct consequence of the chosen algorithm. It is mathematically so demanding that executing it thousands of times in succession will inevitably take a long time.
I am slowly expanding it but this is not very fast to code with following features:
Ideas for Expanding Histogram Bars (with ALGLIB Splines)
Based on Derivatives from spline1ddiff (Velocity ds and Acceleration d2s)
1. Acceleration Inflection Point (Color)
ALGLIB Function: spline1ddiff
Logic: Change the bar color to a special warning color (e.g., yellow) whenever the acceleration (d2s) changes sign. This happens exactly at the peak or bottom of momentum.
Why it works: Marks the exact moment when the price movement switches from “full throttle” to “braking” (or vice versa), often anticipating a price reversal.
2. Dynamic Ratio Index (Height/Color)
ALGLIB Function: spline1ddiff
Logic: Compute the ratio: abs(ds / d2s). Assign bar color or even height based on this ratio.
Why it works:
A small ratio means acceleration dominates over velocity → explosive movement.
A large ratio means velocity dominates but acceleration is weak → a mature trend.
A collapse in this ratio is a strong warning signal.
3. Third Derivative “Jerk” (Color)
ALGLIB Function: spline1ddiff (manually computing the change of d2s)
Logic: Calculate acceleration’s rate of change (d2s
- d2s[i-1]). If this “jerk” exceeds a threshold, color the bar with a special highlight.
Why it works: Reveals sudden, hidden shifts in market dynamics. A strong positive jerk in a downtrend may be the first sign of a bottom forming.
4. Divergence of Derivatives (Color)
ALGLIB Function: spline1ddiff
Logic: Detect when the price makes a new high but the velocity (ds) does not. Color bars in this region (e.g., purple).
Why it works: A classical divergence signal indicating the underlying strength of the trend is fading.
5. Momentum Braking Distance (Height)
ALGLIB Function: spline1ddiff
Logic: In an uptrend, when acceleration (d2s) turns negative, start counting how many bars pass before velocity (ds) reaches zero. Use this count as bar height or color.
Why it works: Quantifies the “rollout distance” of a trend.
A short braking distance → abrupt stop.
A long braking distance → gradual topping out.
Based on Noise Filtering with spline1dfitcubic
6. Filtered Acceleration Signal (Color/Height)
ALGLIB Functions: spline1dfitcubic, spline1ddiff
Logic: Compute velocity and acceleration from the fit spline (not raw data). Use these smoothed values for bar height and color.
Why it works: Produces a much smoother, more stable view of dynamics, filtering out false signals from random spikes. Excellent for identifying the overall trend picture.
Based on Area Calculation with spline1dintegrate
7. Momentum Energy (Color)
ALGLIB Functions: spline1ddiff, spline1dintegrate
Logic: Integrate the absolute velocity (|ds|) over the last N bars. This represents the “total energy” of the movement. Color bars by the intensity of this energy.
Why it works: If energy fades while price still rises, it strongly signals trend exhaustion.
Mixed & Combined Spline Ideas
8. Hermite Spline Stress Indicator (Color)
ALGLIB Functions: spline1dbuildcubic, spline1dbuildhermite
Logic: Build two splines — a normal cubic spline and a Hermite spline (using derivatives as input). Color bars based on the difference between the two splines.
Why it works: The difference expresses stress or disagreement between price and its instantaneous momentum. A large difference may anticipate a correction.
9. Catmull-Rom “Oversmoothness” Divergence (Color)
ALGLIB Functions: spline1dbuildcubic, spline1dbuildcatmullrom
Logic: Compare the cubic spline to the smoother Catmull-Rom spline. When they differ significantly, it means short-term movement deviates from the long-term smooth trend.
Why it works: Acts like an embedded fast vs. slow signal comparison, revealing hidden tensions.
10. Acceleration Zero-Crossing Frequency (Height)
ALGLIB Function: spline1ddiff
Logic: Count how many times acceleration (d2s) crossed zero over the last N bars. Use this count as bar height.
Why it works:
A high count = choppy, unstable market with constant reversals.
A low count = stable trend.
Reversals often follow after a choppy phase.
11. Hidden Momentum Accumulation (Special Bar)
Logic: When velocity (ds) stays near zero (consolidation), but acceleration (d2s) steadily rises over several bars, draw a special bar (e.g., small square).
Why it works: Reveals silent power buildup before a breakout. A classic “calm before the storm” signal.
12. Structural Change in the Spline (Color)
ALGLIB Function: spline1dunpack
Logic: Unpack spline coefficients and track their changes. Sudden shifts in coefficients (even with stable prices) indicate a structural change.
Why it works: A very sensitive way to detect hidden changes in market character invisible to the naked eye.
13. Dispersed Bar (Drawing Style)
Logic: The larger the difference between spline1dbuildcubic and spline1dfitcubic (i.e., noise), the more grainy or dispersed the bar should be drawn.
Why it works: Visualizes uncertainty.
Clear, solid bars = reliable signal.
Dispersed bars = noisy, unreliable signal.
Ideas for Expanding the Blue Raw Signal (“Smart Price”)
14. Noise-Filtered Raw Signal
ALGLIB Function: spline1dfitcubic
Logic: To Replace the current spline1dbuildcubic with spline1dfitcubic for ENUM.
Why it works: Produces a much smoother and more stable signal line, less sensitive to single price spikes. Shows the true average market direction more clearly.
15. Predictive Hermite Spline
ALGLIB Function: spline1dbuildhermite
Logic: Build the blue line using a Hermite spline that takes both price and its instantaneous velocity as input.
Why it works: Since the spline “knows” the current direction during construction, it often turns earlier and more sharply than a normal cubic spline.
https://asmquantmacro.com/2015/09/01/ak ... -in-excel/
The Core Engine of the Indicator
How the Engine Works Step by Step (GetCachedSplineValue Function)
In Summary
Cause-and-Effect in Detail
The result: the indicator doesn’t perform one heavy calculation, but instead performs each candle consecutive heavy calculations immediately on startup. This is why the process easily takes 5–10 seconds and why the interface “freezes” (the indicator window goes blank) during this time.
Final Summary
