Re: [Gretl-users] GARCH Conversion
On Thu, 21 Jun 2018, Periklis Gogas wrote:
I am using Gretl with a class of graduate students and for one of
the assignments they have to estimate the optimum GARCH
specification based on their data. Each student uses different
stock prices as the variable in question.
When they use both options:
1. Model > Time Series > GARCH
2. Model > TIme Series > GARCH Variants
We seldom get results as the vats majority of models do not
converge. This makes it very difficult to use Gretl in class. Why
is this? What is the problem? The same data with the same
specification run and get results in Eviews for example.
Bellow I have estimated an AR(10) model with an ARCH(1)
specification just to show you the problem.
Using Gretl I get this:
(alternative link: http://i64.tinypic.com/23sc5zq.jpg)
[image: screenshot_1895.jpg]
And using Eviews with exactly the same specification and data I get this:
(alternative link: http://i65.tinypic.com/2yv3vj6.jpg)
[image: screenshot_1896.jpg]
And this happens a lot of times with alternative ARCH/GARCH specifications
rendering Gretl impossible to use in class for these types of models.
Any ideas?
As Jack says, it would be usual to apply GARCH to the log-difference
of a stock price rather than its level. And in the past we have seen
cases where Eviews "panders to the user" by producing estimates even
when true convergence has not been reached. But we can't really
offer informed comment without seeing an example of data on which
gretl reports convergence failure.
That said, I tried the following, designed to roughly emulate the
case you show, namely ARCH(1), with 10 AR lags on the level of a
stock price:
open djclose.gdt
garch 0 1 ; djclose djclose(-1 to -10)
The standard garch command worked OK. I then tried to estimate the
same model via gig:
include gig.gfn
list X = const
bundle gb = gig_setup(djclose, 0, X, null, 10)
gig_estimate(&gb, 2) # 2 for max verbosity
In this case I got failure of convergence, but I could achieve
convergence by specifying GARCH(1,1) rather than ARCH(1):
gb = gig_setup(djclose, 1, X, null, 10)
gig_estimate(&gb)
The "beta" coefficient in this case is large, with a very small
standard error, which suggests that ARCH(1) is misspecified.
Allin
