Returns, log returns and stationarity

A security closes at $100.00 on Monday, $110.00 on Tuesday, and $100.00 on Wednesday. The simple return on Tuesday is $+10\%$. The simple return on Wednesday is $-9.09\%$. Add those two numbers and you get $+0.91\%$ — but the security ended the two days exactly where it started, at 0%. Simple returns do not add up across time, and a researcher who treats them as if they do will misstate every multi-day statistic built on top of them. This is the first thing worth being precise about before building anything else on a price series.

Simple returns and what they measure

A simple (arithmetic) return over one period is the price change scaled by the starting price:

$$r_t = \frac{P_t - P_{t-1}}{P_{t-1}}$$

Simple returns answer the question “how much money did I make or lose, in proportion to what I put in.” They are the right basis for portfolio-level arithmetic: if a portfolio holds $60\%$ in Security A and $40\%$ in Security B, the portfolio’s simple return over the period is the weighted sum of the two simple returns, $0.60 \, r_A + 0.40 \, r_B$. That additivity across securities at a single point in time is simple returns’ genuine advantage, and it is why portfolio weighting and rebalancing arithmetic in Quant Compose’s risk and portfolio modules is built on simple returns.

What simple returns do not do cleanly is compound across time. Growing $100.00 by $10\%$ then shrinking by $9.09\%$ does not average to a $0.5\%$ per-day return; the true multi-day return has to come from multiplying gross returns together: $(1 + 0.10)(1 - 0.0909) = 1.0000$, i.e. exactly flat, matching the actual $100.00 \rightarrow 100.00$ path.

Log returns and why they compound additively

A log-returnLog return The natural logarithm of the ratio between consecutive prices, used because log returns are additive across time and closer to normally distributed than simple returns. is defined as the natural logarithm of the gross return:

$$r_t^{\log} = \ln\left(\frac{P_t}{P_{t-1}}\right)$$

Using the same two-day example: $r_1^{\log} = \ln(110/100) = 0.09531$, and $r_2^{\log} = \ln(100/110) = -0.09531$. These sum to exactly zero, matching the flat two-day price path. That is the structural reason log returns exist: they turn multiplicative compounding into simple addition, because $\ln(P_2/P_0) = \ln(P_1/P_0) + \ln(P_2/P_1)$ for any price path. A multi-day log return is just the sum of the daily log returns — no compounding formula required, no approximation error from treating a multiplicative process as additive.

This additivity is why volatility estimation, time-series models such as ARIMA and GARCH, and most statistical hypothesis tests in the data-preparation pipeline operate on log returns rather than simple returns: the underlying mathematics of those models assumes additive, time-aggregable increments, and log returns are the representation that actually has that property.

A worked comparison over five days

Day	Close	Simple return	Log return
0	100.00	—	—
1	105.00	5.000%	4.879%
2	98.70	−6.000%	−6.186%
3	103.63	5.000%	4.879%
4	90.90	−12.283%	−13.096%

Summing the log-return column gives $4.879 - 6.186 + 4.879 - 13.096 = -9.524\%$, and $\ln(90.90/100.00) = -9.524\%$ exactly — the additivity holds to as many decimal places as the arithmetic is carried. Summing the simple-return column gives $-8.283\%$, which is not the four-day return at all; the correct four-day simple return has to be computed by compounding the gross factors, $(1.05)(0.94)(1.05)(0.87717) - 1 = -9.10\%$, which is the actual peak-to-trough change from $100.00$ to $90.90$.

Stationarity: the assumption almost everything else relies on

A price series is not stationaryStationarity A property of a time series whose statistical characteristics — mean, variance, autocorrelation — do not change over the sample. — its mean and variance drift with the level of the price, which is precisely why nobody fits a regression directly to a price level and expects the result to mean anything. A weakly stationary series has a mean, variance and autocovariance structure that do not depend on the point in time at which they are measured. Log-return series are, under reasonable assumptions about the underlying price process, much closer to stationary than the price level itself, which is the second reason they are the default representation for statistical work: a rolling-window volatility estimate, an autocorrelation function, or a GARCH fit only means what it claims to mean if the series it’s applied to has a roughly stable statistical character across the window.

Two of Quant Compose’s validated hypothesis tests exist specifically to check this rather than assume it. The Augmented Dickey-Fuller test has a null hypothesis of a unit root — non-stationarity — so rejecting the null is evidence in favour of stationarity. The KPSS test has the opposite null, stationarity, so failing to reject KPSS is also evidence in favour of stationarity; running both is more informative than running either alone, because ADF has notoriously low power against near-unit-root processes, and a series can fail one test’s specific alternative while genuinely being borderline. A series that fails ADF (does not reject the unit-root null) and fails KPSS (does reject the stationarity null) is a real disagreement worth investigating before building a model on top of it, not a result to average away.

Fractional differentiation: stationarity without discarding memory

Differencing a series — working with period-over-period changes instead of levels — is the classical route to stationarity, and a log return is itself a first difference of the log price. But full differencing can remove more memory from a series than strictly necessary to achieve stationarity, discarding structure a model might otherwise use. Fractional differentiation, one of the feature-construction methods in Quant Compose’s catalogue, differences a series by a fractional order rather than an integer one, aiming for the minimum amount of differencing that achieves stationarity while retaining as much of the series’ memory as possible. It is currently unverified against a published reference case in the workspace’s validation registry, which is a statement about the state of third-party cross-checking, not a statement that the method is unsound — the distinction the workspace draws throughout its method catalogue between validated and unverified.

Why this matters before a single feature is built

Every downstream statistic — a Sharpe ratio, a rolling volatility estimate, a feature computed on a return window — carries an implicit assumption about which return convention it is being fed and whether that series behaves consistently across time. Getting this wrong at the very start of a pipeline, before the steps described in Preparing financial time series are even applied, means every later number inherits an error that traces back not to a model choice but to a definitional one. The same reasoning determines which comparison baseline is even meaningful for a given series, a question explored in Benchmarks and why your comparison set matters.