[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
"gary tian" <g.tian@uws.edu.au> |

To |
<statalist@hsphsun2.harvard.edu> |

Subject |
RE: st: GARCH estimation time issue |

Date |
Fri, 3 Jun 2005 09:42:08 +1000 |

Dear Vince and all others, Thank a lot for your message and explanation, which are very helpful. I would like to ask one more question. Is there any build-in function to estimate GARCH or EGARCH with generalised error distribution (GED) or we have to program by ourself. Eviews has such facility, I would like to compare the results from these two. But more importantly, Stata is much easy to use for repeated jobs by LOOP. Thanks in advance. -----Original Message----- From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu]On Behalf Of Vince Wiggins,StataCorp Sent: Friday, 3 June 2005 1:35 AM To: statalist@hsphsun2.harvard.edu Subject: Re: st: GARCH estimation time issue Gary Tian <g.tian@uws.edu.au> 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 vwiggins@stata.com * * 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/ * * 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/

**References**:**Re: st: GARCH estimation time issue***From:*vwiggins@stata.com (Vince Wiggins, StataCorp)

- Prev by Date:
**st: Upcoming NetCourses** - Next by Date:
**Re: st: labels as values of a string variable** - Previous by thread:
**Re: st: GARCH estimation time issue** - Next by thread:
**st: RE: [8] today() ?** - Index(es):

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