Simple Moving Average (SMA): Define the Window Before the Mean

Six observations arrive:

The latest value is 18. Is the recent level 18? Not necessarily. One observation can be noisy, so we ask a more stable question:

What is the average of the latest three accepted observations?

At the sixth observation, those values are 15, 14, and 18:

That is a three-observation Simple Moving Average. The arithmetic is elementary. The contract around the arithmetic is where robust financial software begins.

The learning promise

By the end, you will be able to:

• identify exactly which values enter a finance-style SMA;
• calculate it directly or with a constant-time rolling update;
• explain why early nulls, missing timestamps, and adjusted prices matter;
• distinguish causal SMA from centered, partial-window, cumulative, and time-based variants;
• implement matching Python and TypeScript versions;
• understand why SMA is the right prerequisite for EMA.

One formula, several hidden choices

For a window of $n$ observations:

Here:

• $x_t$ is the current accepted observation;
• $n$ is a positive integer window length;
• $t$ counts accepted observations, not necessarily calendar days;
• the result is attached to the newest point in the window.

This is a trailing or right-aligned average. It uses the current observation and $n-1$ earlier observations. It is causal because it never uses a value after $t$.

Every window member has the same weight:

and the weights sum to one:

That gives the SMA two useful properties.

First, shifting every value by the same constant shifts the SMA by that constant. Second, the result must lie between the smallest and largest values in the active window:

If a calculated SMA lies outside that range, something is wrong with the data, window membership, or implementation.

“Moving” means replacement

Start with the first complete three-value window:

so:

One observation later, the window is no longer $10,13,12$. Value 10 leaves, values 13 and 12 stay, and value 15 enters:

The direct calculation is correct, but repeatedly summing all $n$ values costs $O(n)$ work per output. A rolling sum expresses the window movement directly:

For observation 4:

and:

The incoming/outgoing bookkeeping is the direct mean reorganized, not a different estimator. Open the diagram at full size.

The rolling recurrence is not an approximation to the direct formula. In exact arithmetic, it is the same formula reorganized. It turns the per-observation calculation into $O(1)$ work.

The complete example

Use:

The canonical full-window calculation is:

The full-precision output is:

[null, null, 11.666666666666666, 13.333333333333334,
 13.666666666666666, 15.666666666666666]

The raw series moves down at observation 3 and observation 5. The three-point SMA changes more gradually because every result combines three observations.

The three-observation line starts only after warm-up and changes more gradually than the synthetic raw values. It demonstrates smoothing and lag, not predictive success. Open the chart at full size.

This smoothness has a cost: lag. At observation 6, the raw value has reached 18 while the SMA is 15.6667. A longer window usually reduces short-run variation more strongly, but it also waits longer for readiness and responds more slowly to a new level.

Warm-up is part of the answer

At observation 1, the system has one value—not three. At observation 2, it has two. The canonical result is null for both.

Why not calculate $10/1$ and $(10+13)/2$? You can, but that is a partial-window mean:

Its denominator changes during warm-up. The first result averages one value, the next averages two, and later values average three. Those early outputs do not have the same statistical meaning as the declared three-observation SMA.

This package therefore sets:

minimum_periods = window

and emits null until readiness. pandas exposes this choice explicitly through rolling-window parameters, and its fixed-window examples show nulls before the first complete mean. A production API should do the same rather than hiding a default.

The playground includes partial-window behavior for comparison, but labels it as a variant.

Open the SMA Window Lab

Try window lengths 1 through 5. Notice three linked effects:

1. a larger window takes longer to produce its first canonical result;
2. it combines more observations;
3. it generally creates a smoother, slower-moving line.

Trailing and centered averages are not interchangeable

A centered three-point average at observation $t$ uses:

The future value $x_{t+1}$ is part of the result labeled at $t$. Centering is useful for retrospective trend-cycle estimation, but it is not available in real time at the centered timestamp.

A trading study that calculates a centered average and acts as though it was known at $t$ contains look-ahead bias.

The canonical finance SMA is trailing:

It uses only information available by the close of observation $t$, assuming the source point itself is final and the decision timing allows its use.

Observation windows are not time windows

Suppose daily values exist on Friday, Monday, and Tuesday. A three-observation SMA contains those three accepted sessions. The weekend does not add two zero observations.

This is a fixed-count contract:

window = 3 accepted observations

A time-based rolling rule such as “all observations in the previous 72 hours” is different. Its count can change across weekends, holidays, outages, and irregular event streams.

Neither choice is universally right. The error is describing one and implementing the other.

For market data, record:

• calendar identity;
• frequency;
• timezone and timestamp meaning;
• whether the timestamp represents open, close, settlement, or publication;
• how missing sessions and halted instruments are represented.

A bounded historical example: official SOFR observations

The Federal Reserve Bank of New York publishes the Secured Overnight Financing Rate (SOFR) on business days. Its Markets API returned the following effective-date observations for 2–8 January 2024. The SOFR values are provider observations; the SMA values are arithmetic derived for this article.

The 8 January result uses the three accepted observations dated 4, 5, and 8 January:

The weekend does not add two zeros or two carried-forward copies. This is the concrete difference between a three-observation window and a three-calendar-day rule.

The New York Fed's reference-rate publication policy says an initially published reference rate can be revised later the same day under defined conditions. A production SMA should therefore retain observation and revision provenance. Nothing in this five-row example establishes a forecast, signal, causal event, or trading result. The reproducibility record—endpoint parameters, retrieval time, response hash, exact provider values, and derived arithmetic—is stored in the package dataset.

Missing data is not zero

Numeric zero can be a valid observation. Net Advances can be zero. A rate can be zero. A price may not normally be zero, but replacing a missing price with zero would still be a data corruption, not an SMA rule.

This package rejects:

• null;
• NaN;
• positive or negative infinity;
• booleans;
• numeric strings.

An absent timestamp creates no update. The canonical observation-space SMA neither inserts a zero nor carries the last value forward.

If imputation is required, treat it as an upstream transformation with its own provenance. The output then describes an SMA of the imputed series, not an SMA of the original observations.

Price basis can break a window

Imagine four unadjusted closes followed by a two-for-one stock split. The mechanical price drop can dominate a rolling average even though shareholder value did not halve. Mixing unadjusted history with an adjusted current value is worse: the window no longer has a coherent unit basis.

Choose and preserve a value_basis, such as:

• raw close;
• split-adjusted close;
• total-return adjusted close;
• settlement price;
• a named vendor field and adjustment version.

If the source revises its history, every SMA whose window contains a revised observation can change. For window $n$, one revised point can affect up to $n$ right-aligned outputs.

Provisional values need window-local provenance

Suppose today’s input is provisional. Today’s SMA is provisional because that value belongs to its active window. Tomorrow’s and later SMAs remain provisional until the unresolved value exits or becomes final.

For a finite-window SMA, provisional influence has a clear boundary. This differs from a recursive EMA, where a revised observation can influence all later states unless the series is recomputed or state is corrected.

A useful output row therefore carries:

• whether the current source value is provisional;
• whether any observation in the active window is provisional;
• the active window’s start and end;
• source revision or snapshot identifiers.

Reference implementation

The Python core:

def calculate_sma(values, window):
    if not isinstance(window, int) or isinstance(window, bool) or window < 1:
        raise SMAValidationError("window must be a positive integer.")

    numbers = validate_finite_values(values)
    result = []
    rolling_sum = 0.0

    for index, value in enumerate(numbers):
        rolling_sum += value
        if index >= window:
            rolling_sum -= numbers[index - window]
        result.append(None if index + 1 < window else rolling_sum / window)

    return result

The TypeScript version uses the same branch structure:

export function calculateSma(
  values: readonly number[],
  window: number,
): Array<number | null> {
  validateWindowAndValues(values, window);
  const output: Array<number | null> = [];
  let rollingSum = 0;

  values.forEach((value, index) => {
    rollingSum += value;
    if (index >= window) rollingSum -= values[index - window];
    output.push(index + 1 < window ? null : rollingSum / window);
  });
  return output;
}

The package implementation expands the validation helpers and uses one JSON fixture set for both languages. A second boundary function, calculate_sma_series in Python and calculateSmaSeries in TypeScript, validates timestamp order, source identity, unit, calendar, frequency, value basis, and finality before producing auditable rows. The short array function above remains the intentionally narrow numeric core.

Numerical behavior

The formula should keep full floating-point precision. Rounding every SMA for display is fine; rounding the rolling sum before the next update is not.

Binary floating-point cannot represent every decimal fraction exactly, and repeated add/subtract updates can accumulate small error in very long streams. Three practical controls are:

1. define an absolute and relative tolerance in tests;
2. periodically rebuild the sum from the retained window when the error budget requires it;
3. use compensated summation for demanding magnitude ranges.

Do not introduce a different numerical policy in only one language. Cross-language parity is part of reproducibility.

Tests that catch semantic errors

Arithmetic tests are necessary, but contract tests catch more dangerous failures.

Canonical fixture

Verify every output, including the first two nulls.

Window one

If that fails, indexing or readiness is wrong.

Window longer than history

Every canonical output must be null.

Translation invariance

For constant $c$:

This catches some membership and denominator mistakes.

Range invariant

Every ready result must remain between the active window’s minimum and maximum.

Invalid data

Reject invalid windows, null-like values, NaN, infinity, booleans, and ambiguous strings.

Direct-versus-rolling check

For generated finite sequences, compare each rolling output with an independently summed window within the declared tolerance.

Provenance and historical arithmetic

Reject duplicate or decreasing timestamps and any mid-run change in series identity, unit, calendar, frequency, or value basis. Verify that provisional state persists exactly while the provisional source row remains inside a ready window. Recalculate the five-row New York Fed illustration from the stored provider observations rather than treating its displayed rounded values as test inputs.

Common mistakes

Calling a cumulative mean an SMA

A cumulative average uses all history:

Its memory grows. An SMA’s memory remains $n$.

Treating 20 as calendar days

Most finance chart conventions mean 20 accepted observations. A time-duration window needs a different API and tests.

Silently emitting partial windows

Early numbers look plausible but use changing denominators.

Centering a backtest feature

The line looks visually balanced because it uses future data.

Rounding state

Presentation precision leaks into calculation and creates platform disagreement.

Mixing adjustment bases

The window averages quantities that are not economically comparable.

Confusing smoothing MA with MA($q$)

In time-series modeling, a moving-average model combines current and past random shocks. It is not this rolling mean of observed prices or indicators.

What SMA can and cannot tell you

SMA can answer:

• What is the equal-weight mean of the latest $n$ accepted observations?
• Is the current observation above or below that recent mean?
• How has a smoothed historical level changed?

SMA alone cannot answer:

• Will the next price rise?
• Is a chosen window optimal?
• Will a crossover remain profitable after costs?
• Is a structural break temporary or permanent?
• Is the source history free of survivorship or revision bias?

Those require separate models, evaluation, and controls.

The bridge to EMA

SMA has a hard window edge. A value has weight $1/n$ while it remains inside, then its weight becomes exactly zero.

EMA behaves differently. It updates recursively:

Older influence decays geometrically rather than disappearing at a single window boundary. In the canonical EMA topic, the first state is seeded with the SMA of the first $n$ observations.

That makes SMA the right first topic. Once you understand:

• what a window contains;
• when a full result exists;
• why input order and basis matter;
• how a seed is calculated;

you can focus on the genuinely new EMA ideas: alpha, persistence, recursive state, and infinite theoretical memory.

Final checklist

Before accepting an SMA implementation, ask:

• Is the window fixed-count or elapsed-time?
• Is it trailing or centered?
• Is the label attached to the newest point?
• Must a full window exist?
• What happens to missing values and missing timestamps?
• Are values finite and consistently adjusted?
• Is zero treated as data?
• Is precision retained internally?
• Can revisions be traced and recomputed?
• Do Python and TypeScript match the same fixture?

If those answers are explicit, the Simple Moving Average is not just a formula. It is a reproducible financial data contract.

References

Definitions and convention evidence are documented in REFERENCES.md, including NIST sources for moving-average smoothing and centering, pandas rolling-window semantics, and official New York Fed sources for the bounded SOFR illustration and revision timing.