Gary Tian <[email protected]> asks why Stata's estimates of a simple
generalized autoregressive conditional heteroskedasticity (GARCH) model agree
with estimates from Eviews and Shazam while those from a model with additional
multiplicative heteroskedasticity do not. Gary asks,
> I estimate GARCH model using intraday data about 30,000 observations
> for 30 individual stocks.
>
> When I use following estimation for one stock, the coefficients are
> same with Eviews and Shazam [...]
>
> arch r l.r, arch(1) garch(1) nolog
>
> When I add volume in the variance equation to the following estimeation,
>
> arch r l.r, het(vol) arch(1) garch(1) nolog
>
> The problem is that the values of coefficients from Stata are very
> different from those of Eviews and Shazam but significant levels are
> same.
The option -het(vol)- adds multiplicative heteroskedasticity modeled on the
variable -vol- to the conditional heteroskedasticity specified by the options
-arch(1)- and -garch(1)-.
There are several reasons why the results might differ.
1) ARCH/GARCH models have a particularly difficult likelihood to optimize
and it is possible that the other packages have stopped at a different
point on the likelihood surface. The likelihood is especially
difficult when multiplicative heteroskedasticity is included (as it is
in Gary's second model). ARCH models were one of the reasons Stata
changed its default convergence criterion to the Hessian-scaled
gradient (HSG) in Stata 8. Difficult likelihoods, such as those from
ARCH models, often cause other stopping rules to stop iterating before
a maximum has been obtained. The HSG ensures that a maximum has been
found, i.e., that the gradient of the likelihood is zero when it
scaled by the curvature of the likelihood (the Hessian). As an ad-hoc
check, Gary may want to look at the likelihoods and see which is
larger.
2) Eviews and Shazam may be using different priming values in computing
the likelihood. The likelihood for ARCH models is evaluated
recursively and requires presample estimates of the conditional
variance -- priming values. Stata, by default, uses the unconditional
variance as implied by the current coefficient estimates. I am not an
expert on Eviews or Shazam, but my recollection is that Eviews uses
different priming values. You can change the priming values in Stata
using the -arch0()- option; the computations are described in
"Priming values" in the "Methods and formulas" section of [TS] arch. I
believe that Eviews uses a computation that matches the -arch0(xbwt)-
specification which weights the early observations more heavily in
computing the priming values. Asymptotically it does not matter what
priming values are used, but they can have a potentially large effect
on the estimates from small or even large samples.
3) Eviews and Shazam may be using additive heteroskedasticity rather than
multiplicative heteroskedasticity when modeling the additional variance
on the variable -vol-. As documented in the option description for
-het()-, this option adds multiplicative heteroskedasticity as modeled
on the variables specified. Thus the conditional variance becomes,
cond_var = exp(a0 + a1*vol) + ARCH/GARCH terms
Eviews and Shazam may be estimating additive variance terms
cond_var = c0 + c1*vol + ARCH/GARCH terms
Multiplicative heteroskedasticity is more numerically stable -- you do
not run the risk of adding negative terms to an expression that must be
a positive variance.
Gary goes on to ask,
> I check Eviews I use Marquardt optimal algorithm. Ok, so I change to
> following estimation of BFGS algorithm:
>
> arch r l.r, het(vol) arch(1) garch(1) nolog bfgs
>
> I wait to 45 minutes, it didn't give me results, so I stop it.
I suspect the Broyden, Fletcher, Goldfarb, and Shanno (BFGS) algorithm is not
converging or that BFGS is simply taking an inefficient path to the solution.
Nonlinear optimization can be problematic and ARCH likelihoods are
particularly difficult. That is one reason why Stata offers several different
optimization methods -- sometimes a likelihood can be more easily optimized
using a different method. Since convergence was achieved with Stata's default
optimization method, I would not expect results using BFGS to differ.
As I noted in 1) above, Stata has a very stringent definition of convergence.
Stata does not stop iterating and declare convergence simply because the
coefficients are not changing or because the likelihood is not changing, Stata
insists that the multivariate slope of the likelihood -- the gradient- is zero
as scaled by the Hessian.
-- Vince
[email protected]
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
