How Frama Is Calculated

Direct answer: what “Frama” calculation means

FRAMA (often written as “Frama”) stands for FRactal Adaptive Moving Average. It is calculated to produce a moving average whose smoothing strength adapts to how “complex” or “trending” the recent price action appears. The adaptation comes from estimating a fractal dimension from price ranges over multiple lookback windows, and then converting that estimate into an effective smoothing factor.

A key point is that Frama’s value is not produced from a single formula using one parameter only. It depends on:

• the chosen lookback lengths,
• the price data definition (e.g., using high/low ranges derived from OHLC),
• and the mapping from fractal dimension to the smoothing factor.

The mechanics: inputs and core calculation steps

1) Define the data and “range” used

Most Frama implementations use the range of price over a window, typically derived from high and low values. A standard range concept is:

• Range over a window: a measure such as (highest high − lowest low) within that window.

If you are verifying a calculation yourself, the first task is to fix the exact definition of “range” your source uses, because changing the range definition changes the resulting Frama series.

2) Split the main lookback into subwindows

A typical Frama design uses a main window length (call it N). To estimate fractal behavior, the algorithm considers:

• a range over the last N bars, and
• ranges over two consecutive subwindows of length N/2 (when N is even).

That means for a bar at time t you conceptually compute:

• Range1: range over the first subwindow,
• Range2: range over the second subwindow,
• RangeTotal: range over the full window.

3) Compute a fractal-dimension estimate

Fractal dimension (in the Frama sense) is estimated from how RangeTotal compares to Range1 and Range2. A common approach is to convert the ratio into a dimension value that increases when price movement looks more irregular, and decreases when it looks more like a smooth trend.

Because there are multiple versions in practice, verification requires checking your chosen reference for the exact mapping from the range ratios to the fractal dimension.

4) Convert fractal dimension into an adaptive smoothing factor

Once a fractal-dimension estimate is available, Frama turns it into a smoothing factor. The idea is:

• when the estimated complexity suggests “more noise,” the smoothing becomes stronger (slower response),
• when it suggests “more trend-like structure,” the smoothing becomes weaker (faster response).

Again, the exact conversion is implementation-dependent. Many variants use parameters such as minimum/maximum smoothing bounds to keep the smoothing factor in a practical range.

5) Apply an exponential smoothing update

Finally, Frama updates recursively in the style of a moving average:

• the new Frama value at time t is a blend of the current price (or a chosen proxy such as a mid-price) and the previous Frama value,
• where the blend weight is the adaptive smoothing factor computed in steps 2–4.

So even when the fractal dimension math is correct, you still need to verify:

• what “current price” is used in the update (close vs. mid-price), and
• how the first Frama value is initialized.

Evidence or example: how to verify a Frama calculation without trading assumptions

Because the exact formula can vary across sources, the most reliable way to verify “how it is calculated” is to reproduce it from fixed assumptions on a small dataset.

A self-check procedure

1. Pick a short historical slice and a fixed bar definition (e.g., OHLC with high/low and close).
2. Choose N and the subwindow split rule (e.g., N/2 each side, requiring an even N).
3. Compute Range1, Range2, and RangeTotal using the same range definition as your target source.
4. Apply the fractal-dimension mapping exactly as stated in that source.
5. Compute the adaptive smoothing factor and then the recursive Frama update.
6. Compare your final series values to the target output for the same inputs.

Material assumption to state explicitly

State your assumptions in your notes:

• whether you used (highest high − lowest low) as range,
• whether you used close or mid-price in the final update,
• how you handle the first N bars (no output, warm-up, or initialization),
• and whether you use even-only N or rounding for subwindows.

If you change any of these, you should expect Frama values to change—even if you kept the same “headline idea” of fractal adaptation.

Limitations and failure modes

1) Implementation differences are common

“Frama” is an algorithmic concept, but different platforms and articles may use different details for:

• the fractal-dimension mapping,
• the smoothing bounds,
• the price proxy in the update,
• and the initialization.

So you cannot safely compare Frama values across providers unless the computation details match.

2) Range-based inputs can be sensitive to noise

Using high/low ranges means the indicator can react strongly to intrabar extremes. In choppy conditions, random swings can change the range ratios and therefore the adaptive smoothing factor, even when the underlying “trend” is not clear.

3) Parameter choices can dominate behavior

Lookback length and any smoothing bounds strongly affect how quickly Frama adapts. A short window tends to be more responsive but can also be more unstable. A longer window tends to be smoother but can lag. This is a mathematical and statistical trade-off, not a guarantee of correctness.

4) Recursive indicators depend on initial conditions

Because Frama is typically recursive, early initialization decisions and warm-up handling can affect later values. Over long histories the influence may diminish, but during shorter samples it can matter.

Verification and next question to ask

To explain Frama accurately to someone else, produce three things:

1. The exact formula details you are using, including how range, fractal dimension, smoothing factor, and recursive update are defined.
2. A list of required inputs (at least high/low and a price for the update step) and the needed parameters (e.g., N and any smoothing bounds).
3. One limitation statement based on the implementation choices you assumed (e.g., sensitivity to high/low noise or dependence on initialization).

A useful next question is: how do the settings you choose change the balance between responsiveness and smoothing? If you share the specific parameter names and the price/range definitions from the source you are using, the Frama calculation can be checked step-by-step against your dataset.