Direct answer
To assess Rate Of Change (ROC), you need (1) a consistent underlying time series (usually prices), (2) a clearly defined sampling rule and lookback window, (3) the exact calculation formula and units, and (4) data-quality and provenance checks so you can verify the input and reproduce the output. Because ROC is sensitive to how data is sourced and sampled, those checks are often more important than the indicator label.
Mechanism or definition
Rate Of Change measures how much a value changes between two points in time. In many trading-context uses, the “value” is a price from a time series, such as the last price per bar.
To apply ROC, you need to specify:
- The input series: which field you use (for example, close/last, open, high, low). Use the same field consistently.
- The lookback period (n): the number of time steps between the “current” value and the “past” value.
- The timeframe: the bar duration (for example, 1 minute, 1 hour, daily). Changing timeframe changes the relationship captured by ROC.
- The formula and units: common variants include percentage change vs. absolute change. State whether ROC is computed as a relative change (dividing by the prior value) or as a raw difference.
Data assumptions you should state
If you compute ROC for an example series, you must assume and record:
- how timestamps map to bars (start/end time convention),
- whether the dataset is complete (no missing bars),
- whether any adjustments were applied (if applicable), and
- whether prices are aligned across instruments (if you compare multiple series).
Evidence or example
Consider ROC computed from a sampled price series. If you define “current” as the value at time t and “past” as the value at time t − n, then ROC requires both values:
- Input at time t: the selected price field from your dataset.
- Input at time t − n: the same price field from n steps earlier.
A material verification step is reproducibility: another person should be able to take your stated series, sampling rule, and formula, and compute the same ROC values. If their results differ, the most common causes are:
- using a different price field (close vs. last),
- using a different bar alignment or timezone handling,
- a different definition of “n” (number of bars vs. a fixed time duration),
- missing or interpolated data points, or
- switching between absolute and percentage change variants.
Limitations and risks
Several limitations affect ROC assessment even when the math is correct:
- Data-quality failure mode: missing bars, duplicate timestamps, or outlier ticks can create spikes in ROC.
- Provenance differences: different data providers may produce slightly different “last” or “close” values due to feed and aggregation rules.
- Timeframe dependence: ROC on short bars may be dominated by noise; on long bars it may react too slowly to capture change.
- No guarantee of usefulness: ROC does not inherently indicate that future movement will follow any past pattern.
- Cost and execution mismatch: if ROC is used to evaluate behavior, real-world frictions (spreads, commissions, execution timing) can break any relationship observed in raw series.
Because outcomes vary with market conditions, costs, and data handling, ROC should be treated as a computed description of change in the chosen series—not as a standalone decision signal.
Verification or next question
To verify ROC information independently, collect and document:
- the exact input series and price field,
- the sampling rule (timeframe and bar boundary convention),
- the lookback period definition (n bars vs. fixed duration),
- the computation formula (absolute vs. percentage), and
- data-quality checks (missing points, outliers, and whether any cleaning rules were applied).
A helpful next question is: Which price field and timeframe does your dataset use, and can you reproduce ROC values from those exact inputs? If reproducibility fails, address the data and definition details first before interpreting the results.