Coding for Trading — Fundamentals

A trading program does not work on numbers, it works on series — one value per bar, indexed by time. Close is not a price, it is a price per bar; and SMA(20) is not an average, it is an average per bar, each computed from the twenty bars ending there.

This is the single mental shift that makes strategy code make sense. Every expression you write is evaluated once per bar, in order, with only the past available. A condition is not a question asked once; it is a question asked on every bar, and the answer changes.

1// what "Close" means to the evaluator2type Series = number[];        // one value per bar, oldest first34const close: Series = [100.2, 101.5, 100.8, 102.4, 103.1];56// what "SMA(3)" means: a new series, same length, computed per bar7function sma(source: Series, period: number): Series {8  return source.map((_, i) => {9    if (i < period - 1) return NaN;          // warm-up: not enough history10    const window = source.slice(i - period + 1, i + 1);11    return window.reduce((a, b) => a + b, 0) / period;12  });13}1415sma(close, 3);  // [NaN, NaN, 100.83, 101.57, 102.10]

Reaching backwards is how a strategy compares now against then. The bracket notation is zero-based from the current bar: Close[0] is this bar, Close[1] the previous one.

The most consequential distinction in strategy logic, and the one most often got wrong. A value condition describes a state that persists. A state change describes a transition that happens once.

1// a value condition: true on every bar the state holds2const isAbove = (i: number) => rsi[i] > 30;3// bars 99,100,101,102 → true, true, true, true45// a state change: true only on the bar the transition occurs6const crossedAbove = (i: number) =>7  i > 0 && rsi[i - 1] <= 30 && rsi[i] > 30;8// bars 99,100,101,102 → true, false, false, false

Used as an entry, the first fires on every bar the condition holds — which means an order on every bar until something stops it. The second fires once. Almost every “why did my strategy take 4,000 trades” question is a value condition where a state change was meant.

Prices and indicator outputs are floating-point numbers, and floating-point arithmetic is not exact. This is not a curiosity — it changes which conditions are safe to write.

10.1 + 0.2 === 0.3;            // false20.1 + 0.2;                    // 0.3000000000000000434// so this comparison can fail even when the values "are" equal5sma20 === sma50;              // unreliable67// compare within a tolerance instead8const near = (a: number, b: number, eps = 1e-9) => Math.abs(a - b) < eps;910// or, better, express the intent as an inequality11sma20 > sma50;                // no equality involved, no problem

A strategy may only use information that existed at the moment it acts. Violating this is look-ahead bias, and it is the one bug that makes a strategy look better rather than worse.

• A bar's close is only known once the bar has ended. Acting on the close of the bar you are evaluating is legitimate; acting on it during the bar is not.
• A bar's high and low are only final at the close. A condition using High mid-bar is using a number that has not settled.
• Anything computed over a centred window uses future bars by construction. A centred moving average is not usable in a live strategy, however good it looks on a chart.
• Fundamental and corporate data carries a publication lag. Using it on its effective date rather than its announcement date is look-ahead.

Every idea in this article, in one worked example: a moving-average crossover with a stop, doing nothing that requires the future and nothing that relies on exact equality.

1interface Bar { open: number; high: number; low: number; close: number }23function run(bars: Bar[]) {4  const close = bars.map(b => b.close);5  const fast  = sma(close, 20);6  const slow  = sma(close, 50);78  let position: { entry: number; stop: number } | null = null;9  const trades: { entry: number; exit: number; reason: string }[] = [];1011  // start at 1: a crossover needs a previous bar to compare against12  for (let i = 1; i < bars.length; i++) {13    // warm-up guard — NaN comparisons are false, but being explicit is clearer14    if (Number.isNaN(slow[i]) || Number.isNaN(slow[i - 1])) continue;1516    if (position) {17      // stops are checked before signals: protection first18      if (bars[i].low <= position.stop) {19        trades.push({ entry: position.entry, exit: position.stop, reason: 'stop' });20        position = null;21        continue;22      }23      const crossedDown = fast[i - 1] >= slow[i - 1] && fast[i] < slow[i];24      if (crossedDown) {25        trades.push({ entry: position.entry, exit: close[i], reason: 'signal' });26        position = null;27      }28      continue;29    }3031    const crossedUp = fast[i - 1] <= slow[i - 1] && fast[i] > slow[i];32    if (crossedUp) {33      position = { entry: close[i], stop: close[i] * 0.98 };34    }35  }3637  return trades;38}

1. 1
   The loop starts at 1

   A state change needs a previous bar. Starting at 0 would compare against undefined and silently never fire.
2. 2
   Warm-up is guarded explicitly

   NaN comparisons are already false, so the guard is not strictly required — but it documents the warm-up region instead of leaving it implicit.
3. 3
   The stop is checked before the signal

   Protection takes priority. If both would trigger on one bar, the stop wins, which is the conservative choice and the one the engine also makes.
4. 4
   Crossings use >= and < on either side

   No equality comparison on a computed average, and the boundary case — exactly equal on the previous bar — is handled deliberately rather than by accident.
5. 5
   Only past and present are read

   Every index is i or i − 1. Nothing reaches forward, so the result is reproducible in real time.