Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: GARCH estimation time issue

From (Vince Wiggins, StataCorp)
Subject   Re: st: GARCH estimation time issue
Date   Thu, 02 Jun 2005 10:34:34 -0500

Gary Tian <> 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

    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

*   For searches and help try:

© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index