Why Garman–Klass Volatility Starts with Missing Values
Summary
The document explains why a rolling Garman–Klass volatility calculation in R returns missing values at the beginning of its output. The TTR implementation forms a daily range-based quantity from OHLC prices, then applies a rolling sum over the specified window before scaling and taking the square root. A full window is needed before the rolling calculation can produce a result, so the earliest observations remain unavailable.
The answer supports this explanation by pointing to the package’s use of a rolling-sum function and showing that a ten-observation rolling sum yields missing values until the first complete window. The question’s interpretation that the estimate uses a trailing period is therefore broadly correct. This is an explanation of initialization behavior, not an evaluation of the estimator’s statistical properties, annualization choice, or suitability for a particular trading task.
Key ideas
- The TTR Garman–Klass calculation uses a rolling sum over the selected window.
- A rolling estimate is unavailable until enough observations have accumulated to fill that window.
- Missing values from the rolling sum carry through into the volatility output.
- The initial missing entries reflect window initialization rather than a failed volatility calculation.
Tags
Full text
# When computing Garman-Klass volatility in R why does it leave out the ten first values?
# When computing Garman-Klass volatility in R why does it leave out the ten first values?
I ran this code in R
```
vGK <- volatility(ohlc, n = 10, calc="garman", N = 260, mean0 = FALSE)
```
and the ten first values appeared like this:
```
[1] NA NA NA NA
[5] NA NA NA NA
[9] NA
```
Is it because the TTR package estimates the average over last 10 days (hence the n=10)? And that's why the values are smoothed?
## Answer by Bob Jansen (score 1, accepted)
https://quant.stackexchange.com/a/33003
Use the source Luke:
```
> library(TTR)
> volatiliy
function (OHLC, n = 10, calc = "close", N = 260, mean0 = FALSE, ...)
{
OHLC <- try.xts(OHLC, error = as.matrix)
calc <- match.arg(calc, c("close", "garman.klass", "parkinson",
"rogers.satchell", "gk.yz", "yang.zhang"))
<snip>
if (calc == "garman.klass") {
s <- sqrt(N/n * runSum(0.5 * log(OHLC[, 2]/OHLC[, 3])^2 -
(2 * log(2) - 1) * log(OHLC[, 4]/OHLC[, 1])^2, n))
}
<snip>
reclass(s, OHLC)
}
```
clearly the `TTR` package is using `runSum` which seems to be rather complicated on it own. However, we can simply do
```
> runSum(1:11, n = 10)
NA NA NA NA NA NA NA NA NA 55 65
```
to see that indeed the first 9 values of `runSum` called with `n = 10` generate 9 `NA` values. In R those `NA`'s will propagate.
This intuitively makes sense for the reason you suggest in your question.Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.