_Heteroskedasticity_ is a fun word to say. It's not a nice thing to find in your time series, though.
Recall that heteroskedasticity is a relationship between the variance of the error term and the independent variable. There shouldn't be a relationship; errors are supposed to be normally distributed around a mean of 0, and the variance of the distribution should be the same everywhere. That's homoskedasticity, and it's what is assumed.
With that in mind, suppose you're working with a time series, and you're looking really closely at the error terms in an autoregression. If there's no heteroskedasticity, and your most recent error was -0.71, what do you expect your next error to be?
Probably not. If you expect this, then you're really assuming serial correlation.
Exactly.
The _expected_ value of any error term should be 0. Make sure you don't confuse this idea with that of variance. It's fine to have variance in the error term. The errors might all add up to 0 (they will), but the average squared error (which is variance) will be positive.
Not likely. That would balance out the last term nicely, perhaps. But this shouldn't be an _expected_ value.
In order to avoid heteroskedasticity (since you know that will cause standard errors to be too small and _t_-statistics to be too large, thereby invalidating statistical inference), you need to make sure that the variance of your error term isn't growing over time; it should be constant. Someone had a nice idea of just regressing squared error terms on past squared error terms, like this:
$$ \hat{\epsilon}_t^2 = a_0 + a_1 \hat{\epsilon}_{t-1}^2 + u_t $$
The _u_ term at the end is the error term here, since the epsilons are already well represented. Now, if you do this on your time series, and there's no heteroskedasticity, what estimated coefficient value should you find?
No, you wouldn't find this. This would suggest that variance is increasing over time. The squared errors would be estimated as the past squared errors plus something, and that shouldn't happen. Those terms should be independent of each other and constant.
Yes!
That's the idea. If the variance of the error term is constant (indicating homoskedasticity), then you can think of variance as being graphed like a line. It should be flat, with a zero slope. If it isn't, you have heteroskedasticity on your hands.
No. The intercept term won't determine anything about heteroskedasticity.
What do you expect that intercept term to be?
Well, no. That would suggest zero variance if the intercept term was also 0.
Right.
Of course, it's fine if the _a_0 value is greater than 0. It should be. Unless you have a perfect series, you'll find some errors, meaning some positive error variance, and that positive value will be _a_0 here.
Testing this in an autoregression like this is a model to test for **A**uto**R**egressive **C**onditional **H**eteroskedascitity (ARCH).
No. That's too broad. This is about variance, and that can't ever be negative.
Now, when you run your test, you might end up with something like this:
| $$ \, $$ | Coefficient | Standard Error | _t_-statistic | _p_-value |
|---|---|---|---|---|
| Intercept | 3.416 | 0.941 | 3.632 | 0.002 |
| $$ a_1 $$ | 0.031 | 0.220 | 0.139 | 0.891 |
How would you interpret this result?
You got it.
No, actually there isn't any ARCH.
The estimated coefficient on the lagged squared errors has a _t_-statistic of just 0.139, so you cannot reject the implied null hypotheses here that this value is equal to 0. This means that the squared errors aren't dependent on each other over time, and there is no reason to believe that your time series has autoregressive conditional heteroskedasticity.
What if it did?
Well, you'd probably need to look at using generalized least squares or some other correction for this. You can't rely on the output if you're facing this ARCH enemy, so to speak.
Some researchers like to extend this to multiple periods for ARCH(2), ARCH(3), up to any ARCH(_p_), which are generalized ARCH models, or GARCH models. But these will give you the same headaches that ARMA models will, with unstable estimates and many questions about specifications. So use with care.
In sum:
[[summary]]