TA library

Every wrun indicator can use ./sdk/ta, which ships with the editor: 52 stateful classes covering averages, statistics, oscillators, ranges, trend systems, and events.

Each class folds one bar per update() call, keeps its own window, and has fixed arithmetic, warm-up, and missing-value rules, checked bit-exact against a reference run. This page is the catalog: every class with its constructor, its update() arguments, its fields, and the one convention you need to know about it. The function pages (Moving averages, Oscillators, Trend and volatility, Volume and VWAP, Series functions) go deeper on each group with compiled examples.

Two sibling modules pick up where the catalog stops, there with classes of the same shape: ./sdk/ta-plus adds the textbook indicators the catalog never had (the double and triple EMAs, TRIX, Kaufman's adaptive average, the ultimate oscillator, Vortex, Aroon, choppiness, the volume lines and more), and ./sdk/stats adds allocation-free list math over a StaticArray<f64> plus History, the x[n] window every indicator needs sooner or later. Both are on Extra indicators; the kits for text, time, colors, order flow, levels and market structure sit beside it in this section.

How every class works

• Allocate in the constructor, never in update(), so per-bar memory stays flat.
• update(...) folds one bar and returns the current value, NaN until the class is warm (a few classes report a partial window from bar 0 instead; the tables say which).
• Multi-output classes fill fields. update() returns the primary line and the other lines sit in public fields you read after the call.
• reset() restores the just-constructed state. Nothing on the chart calls it for you: a revised forming bar replays from a snapshot of the module taken after the last closed bar, so a live update never folds the same bar twice.
• Periods are i32, params are f64. Construct in onStart() from a param (new Sma(i32(p_period()))), keep the object in a module-level let, and update it once per bar in onBar(). A period below 1 is clamped to 1 (except Donchian, which uses the period as given).

The shipped classes

Averages and smoothing

Statistics and series math

Oscillators and momentum

Ranges and bands

Trend systems

Events and conditions

Cross folds three questions into one return value: test > 0, < 0, or != 0.

A composite over the shipped classes: a Macd read through its three fields, a Cross gate over the line and its signal, and an Rsi. The declarations at the top name the four params and the four outputs; the module below them only folds the bars:

param("fast", 12, { min: 1, max: 200 });
param("slow", 26, { min: 2, max: 400 });
param("signal", 9, { min: 1, max: 200 });
param("rsi_len", 14, { min: 2, max: 200 });
output("macd", line, lower);
output("signal", line, lower);
output("rsi", line, lower);
// Data-only: +1 on a bullish MACD cross, -1 on a bearish one, 0 otherwise.
output("crossed", none);

let macd = new Macd(12, 26, 9);
let rsi = new Rsi(14);
let cross = new Cross();

function onStart(): void {
  macd = new Macd(i32(p_fast()), i32(p_slow()), i32(p_signal()));
  rsi = new Rsi(i32(p_rsi_len()));
  cross = new Cross();
}

function onBar(): void {
  const close = bar.close();
  macd.update(close);
  const strength = rsi.update(close);
  const crossed = f64(cross.update(macd.macd, macd.signal));
  if (isNaN(macd.signal) || isNaN(strength)) return;
  out_macd(macd.macd);
  out_signal(macd.signal);
  out_rsi(strength);
  out_crossed(crossed);
}

The catalog by page

Every class grouped by what it does. Every class ships in ./sdk/ta; the page column is where the group is explained with compiled examples.

Moving averages and smoothing

Oscillators and momentum

Trend and volatility

Volume

Statistics

Bars and events

The order book and volume profile scans are not classes: they are loops over a celled input on the Order flow page.

Conventions (read this once)

These rules hold across the library and explain nearly every edge case.

Warm-up is NaN, with named exceptions. A windowed class returns NaN until it has a full window and never fabricates an early value. The classes that report a partial window from bar 0: Sum, Donchian, Ichimoku, Cum (bar 0 is x), Obv (bar 0 is 0), and Stochastic (0 before its window fills). Decide per bar whether to return from onBar() before writing or to write the NaN; either way the chart draws nothing on that bar (Execution model).

Windows are strict; accumulators poison. A class that recomputes over its window (Sma, Wma, Alma, Linreg, Median, Percentile, Variance, Stdev, Correlation, Bb, Highest, Lowest, and the rest of the window family) yields NaN while any value inside the window is not finite and heals as soon as it leaves. A class that carries a running accumulator (Ema, Rma, Atr, Rsi, Macd, Adx, Cum, Psar, Supertrend's ATR) restarts its seed when a non-finite value arrives before the seed completes, and turns NaN for good when one arrives after, because the engine never reseeds. Sum and Zscore skip NaN bars instead. Run a sparse source through Fixnan or an isNaN guard before an accumulator.

Columns are yours to choose. The classes take one value per bar: pass bar.high() to Highest, HighestBars, and PivotHigh for a bar-high window, bar.low() to their counterparts, or the close for a close-based one.

Classes compose. update() takes any f64, including another class's output (rsi.update(sma.update(close))) and any series derived from a celled input. Warm-up propagates through the composition because NaN propagates through arithmetic.

Values carry; events do not. A missing scalar carries the latest eligible value forward by default (the missing policy on the source decides), so math keeps working. Events are stricter: Cross.update() returns 0 on any bar where either side is NaN, BarsSince and ValueWhen read a condition you computed (finite and not 0), so stale data cannot fabricate a signal.

Rma is Wilder. Rsi, Atr, Keltner, and Supertrend share the same accumulator, so an indicator built by hand over Rma agrees with the shipped classes.

Multi-output indicators

An indicator with several streams is a class with several fields. There are no tuple outputs and nothing indexes into an array: update() returns the primary line, and you read the other fields after the call and write each to its own output (Named streams).

Fields feed a band declaration or a box the same way outputs do: write bb.upper and bb.lower to two drawn outputs and declare a range() between their names (Styling), or a box between their handles (Drawing objects).

Over microstructure

Every windowed class also runs over order-flow series, which is where the library stops being a price-only kit. A celled volume_profile input delivers each bar's [low, high, buy, sell] tuples; sum the buy and sell columns into a per-bar delta and the delta is just an f64 any class can fold: an Rsi over it is delta-RSI, a running sum is cumulative volume delta. Declaring the celled input switches the derived sheet to the second runtime contract, and the numeric classes compute exactly as before.

param("period", 14, { min: 2, max: 200, description: "RSI window over the per-bar delta" });
input("close", ohlcv.close);
input("profile", volume_profile.cells, { max_cells: 8192 });
output("delta", line, lower, { color: "#94a3b8", width: 1, description: "Buy minus sell volume across the bar's profile" });
output("delta_rsi", line, lower, { color: "#7c3aed", width: 2, description: "RSI of the per-bar delta" });
output("cvd", line, lower, { color: "#22d3ee", width: 2, description: "Cumulative volume delta" });

let rsi = new Rsi(14);
let cvd: f64 = 0.0;

function onStart(): void {
  rsi = new Rsi(i32(p_period()));
}

function onBar(): void {
  const n = in_profile_cells();
  if (n < 0) return; // this bar carries no block
  let delta = 0.0;
  if (n > 0) {
    const cells = in_profile_view();
    for (let i = 0; i + 3 < n; i += 4) delta += cells[i + 2] - cells[i + 3];
  }
  cvd += delta;
  const deltaRsi = rsi.update(delta);
  out_delta(delta);
  out_delta_rsi(deltaRsi);
  out_cvd(cvd);
}

The Order flow page has every footprint read as a scan over the same tuples, and does the same over book levels for a book-imbalance average.

Accuracy as a contract

Every class is checked bit-exact against a reference implementation. The reference run covers a 690-bar 1h BTCUSDT window; each class is compiled through the real build and executed through the real runtime over the same bars, and every output is compared per bar: a maximum absolute deviation of 0 and identical NaN placement (a bar that is NaN in the reference is NaN here, and only that bar). The conventions on this page are written down so that comparison holds, and a change that drifts a class from the reference numbers fails the build.

Two honest exceptions.

• Ichimoku.chikou is the current close. The engine computes the lagging span by reading close[i + displacement], a bar in the future of bar i, and only falls back to the current close on the last displacement bars of the series. A class that sees one bar at a time cannot read ahead, so the field carries the current close on every bar; it matches the engine on those last bars only. The other four fields match bar for bar.
• Vwap anchors beyond "", "day", and a numeric millisecond width are unproven on that window. The "week", "month", "quarter", and "year" boundaries follow the engine's UTC calendar arithmetic, but the 690-bar window does not exercise a deep-history quarter or year, and the engine's session-calendar bucketing and RTH session filter (venues with a trading-session calendar) are not mirrored, since a per-bar class never sees a session calendar.

Everything else in the catalog, warm-up bars included, matches the reference bar for bar.