Weighted Moving Average (WMA): Newest-Heavy Linear Smoothing

A Simple Moving Average asks every observation in its window to contribute equally. A Weighted Moving Average asks a more specific question:

What is the window’s mean if newer observations receive progressively greater influence?

Take three values:

Give the oldest value multiplier 1, the middle value 2, and the newest value 3:

That is the canonical three-observation WMA used in this topic. The multiplication is easy. Most implementation bugs come from the surrounding choices: weight direction, normalization, warm-up, window movement, missing data, and confusing WMA with other weighted indicators.

What you will build

By the end, you will be able to:

• map values to linear recency multipliers;
• normalize those multipliers into weights that sum to one;
• calculate WMA directly and with a constant-time rolling update;
• distinguish WMA from SMA, EMA, VWMA, and arbitrary-weight averages;
• implement matching Python and TypeScript versions;
• validate the result with invariants rather than one final number.

The required prerequisite is Simple Moving Average. You need to understand a trailing fixed-count window and full-window warm-up. EMA is useful comparison context, but WMA does not require recursive exponential state.

“Weighted” does not define the weights

The general weighted mean is:

NIST's weighted-mean reference and NumPy's maintained average documentation both document this numerator-over-total-weight structure. But that formula does not tell us where the weights come from.

Weights might represent:

• observation recency;
• trading volume;
• measurement precision;
• portfolio exposure;
• survey frequency;
• an arbitrary model specification.

For technical-analysis WMA, the common linear convention assigns the smallest multiplier to the oldest observation and increases by one toward the newest. TradingView's moving-average documentation presents this exact schedule, and its Pine reference describes weights falling in arithmetic progression with age.

This package therefore makes the naming contract explicit:

WMA = trailing linearly weighted moving average
oldest multiplier = 1
newest multiplier = window

An arbitrary-weight moving average is a broader algorithm. A reversed schedule is a valid weighted mean, but it answers the opposite recency question.

The triangular denominator

For a window of length $n$, the raw multipliers are:

Their total is the triangular number:

The canonical WMA is:

For $n=3$:

and the normalized weights are:

They sum to one. The newest value contributes half of the final result.

The multipliers rise from oldest to newest. Open the weight ladder at full size.

Notice the distinction:

• 1, 2, 3 are raw multipliers;
• 1/6, 2/6, 3/6 are normalized weights;
• 10, 26, 36 are weighted products;
• 72 is the weighted sum;
• 12 is the normalized WMA.

Forgetting to divide by six returns 72, which has the wrong scale and is not an average.

The full six-observation example

Continue the D07 fixture:

with window = 3.

The full-precision output is:

[null, null, 12, 13.666666666666666, 14, 16.166666666666668]

The first two outputs are null because a three-observation WMA needs three values. Partial-window weighting would rebuild both the schedule and denominator during warm-up. That is a different contract.

Weight orientation is semantic

At observation 3, canonical weights are:

value:   10  13  12
weight:   1   2   3

Reverse them:

value:   10  13  12
weight:   3   2   1

The reversed result is:

Both results are normalized weighted means. Only the first is this package’s canonical recency-weighted WMA.

This is why an API should not accept an undocumented array called weights. It should either expose a named policy or record the exact vector orientation.

Moving the window efficiently

Direct calculation performs $n$ multiplications for every ready output. That is easy to audit, but a rolling update can do constant work per new observation.

Define the unweighted window sum:

and the linear weighted sum:

When the window advances:

Why subtract the prior unweighted sum? Every retained observation shifts one position toward the oldest edge, so every retained multiplier decreases by one. Subtracting the whole old window applies that one-unit decrease and also removes the outgoing oldest value.

For observation 4:

The unweighted sum moves normally:

Then:

The first ready window initializes both sums. Every later window updates them.

WMA versus SMA

At observation 6, the active values are 15, 14, and 18.

SMA:

WMA:

WMA finishes closer to the newest value, 18, because that observation receives half the total normalized weight.

The two averages use the same observations and window; only the weights differ. Open the comparison at full size.

This does not establish that WMA is better. It establishes that WMA responds to a different weighting preference.

Historical example: one EFFR window, two weight schedules

To see that preference on a real series without turning the example into a performance claim, use five Effective Federal Funds Rate (EFFR) observations published by the Federal Reserve Bank of New York. The rates in this table are provider observations in percent. The SMA, products, and WMA are calculations made for this article.

The equal-weight calculation is:

The newest-heavy calculation is:

The WMA ends closer to the newest observed rate, 4.83%, because the two newest observations carry 9 of the 15 weight units. That is the visible value of the method: the recency preference is explicit and auditable. It is not evidence that WMA predicted the change, explains why it occurred, or produces a tradable signal.

Provenance: New York Fed endpoint rates/all/search.json, queried with startDate=2024-09-13, endDate=2024-09-26, and type=rate; retrieved 2026-07-22T23:23:25Z. Provider data may be revised. The machine-readable example separates provider fields from derived arithmetic, and the source boundary is recorded in S08.

WMA versus EMA

Both WMA and EMA emphasize recent observations, but their memory is fundamentally different.

WMA:

• has exactly $n$ active observations;
• uses a fixed linear ramp inside the window;
• drops the oldest value to zero at the boundary;
• can be recomputed from only the active window.

EMA:

• updates recursively;
• uses geometrically decaying influence;
• retains theoretical influence from all post-seed history;
• depends on prior state and initialization.

Calling EMA “a type of weighted average” is mathematically reasonable. Calling it the same algorithm as finite linear WMA is not.

WMA is not VWMA

A Volume-Weighted Moving Average assigns weights from a second series:

Its weights are volumes, not positions. VWMA requires paired price and volume observations, missing-volume rules, and a zero-volume denominator policy.

WMA needs only one numeric series because its multipliers are generated from position.

The data contract

The numeric core accepts finite values and a positive integer window. A production time-series wrapper also needs:

• strictly increasing unique timestamps;
• stable series identity and unit;
• a declared calendar and frequency;
• a stable value basis, such as adjusted close;
• source finality and revision provenance.

A missing timestamp does not become a zero-weight or zero-value row. It simply creates no accepted observation. Numeric zero, when valid for the series, remains a normal value.

For equity prices, mixing adjusted and unadjusted observations can turn a split into a false trend. For currency data, changing conversion policy changes the unit being averaged. Those are input failures, not moving-average behaviors.

Python implementation

The readable optimized structure is:

denominator = window * (window + 1) / 2
window_sum = sum(values[:window])
weighted_sum = sum(
    weight * value
    for weight, value in enumerate(values[:window], start=1)
)
output.append(weighted_sum / denominator)

for index in range(window, len(values)):
    incoming = values[index]
    outgoing = values[index - window]
    weighted_sum = weighted_sum - window_sum + window * incoming
    window_sum = window_sum + incoming - outgoing
    output.append(weighted_sum / denominator)

The implementation validates all input before emitting results. That prevents partial output from escaping before a later invalid value is discovered. It also rejects an overflowed rolling sum rather than publishing a non-finite WMA from otherwise finite but extreme inputs.

TypeScript implementation

TypeScript mirrors the same state:

const denominator = (window * (window + 1)) / 2;
let windowSum = 0;
let weightedSum = 0;

for (let index = 0; index < window; index += 1) {
  windowSum += values[index];
  weightedSum += (index + 1) * values[index];
}

for (let index = window; index < values.length; index += 1) {
  const incoming = values[index];
  const outgoing = values[index - window];
  weightedSum = weightedSum - windowSum + window * incoming;
  windowSum = windowSum + incoming - outgoing;
}

Both language implementations run against the same JSON fixtures.

Tests that reveal real mistakes

Direct versus optimized

Independently calculate every ready window using explicit products and compare it with the recurrence. This catches update-order errors.

The weighted update must use the prior window_sum. Updating the unweighted sum first changes the formula.

Window one identity

Constant-series preservation

For any constant $c$:

Translation invariance

Range invariant

Every ready output lies between the active window’s minimum and maximum because normalized weights are positive and sum to one.

Monotone-window comparison

For a nondecreasing window, newest-heavy linear WMA cannot be below the SMA of the same values. Reversed weights can violate this expected direction, making the property useful for catching orientation mistakes.

Numerical behavior

The implementation keeps full floating-point precision. Round only when presenting a result.

Long rolling streams can accumulate small binary floating-point differences because the recurrence repeatedly adds and subtracts values. An implementation with strict error bounds can periodically rebuild both sums from the retained window. The policy must be documented and applied consistently across languages.

Explore the weight schedule

Open the WMA Weight Lab.

Try:

1. Step to observation 3 with window 3. Confirm (1×10 + 2×13 + 3×12) ÷ 6 = 12.
2. Switch to oldest-heavy orientation. Confirm the result changes to 11.3333 and the badge says “Variant.”
3. Increase the window to 5. Confirm readiness moves to observation 5 and the denominator becomes 15.
4. Return to the canonical orientation and play through observation 6.

The chart never reveals future WMA values before their observation arrives.

Failure modes

• Reversing the weight vector
• Forgetting to normalize by total weight
• Using a changing denominator during warm-up
• Treating WMA as EMA or VWMA
• Updating window_sum before using its prior value in the recurrence
• Mixing time-based and observation-count windows
• Treating missing data as zero
• Mixing adjusted and unadjusted prices
• Rounding intermediate state
• Claiming responsiveness proves predictive value

Where WMA leads next

WMA is a direct dependency for Hull Moving Average, which combines WMAs of different lengths before applying another WMA. Understanding orientation and period rounding is essential there.

The next tutorial in Trend Smoothing is Wilder RMA. It returns to recursive state, but uses a smoothing constant of $1/n$. That makes it a useful contrast:

• WMA: finite linear position weights;
• EMA: geometric recursive weights with $\alpha=2/(n+1)$;
• Wilder RMA: geometric recursive weights with $\alpha=1/n$.

Summary

A reproducible WMA requires five explicit facts:

1. the window is trailing and fixed-count;
2. the oldest multiplier is one;
3. the newest multiplier is $n$;
4. the denominator is $n(n+1)/2$;
5. output remains null until the full window exists.

Once those are fixed, formulas, optimized code, tests, visuals, and downstream indicators can agree.

References

The evidence register is available in REFERENCES.md, including NIST’s weighted-mean definition, NumPy’s maintained weighted-average contract, TradingView’s linear finance convention, and TA-Lib’s WMA function classification.