On Mon, 17 Jan 2011, [ISO-8859-1] Alejandro Mosi�o wrote:
> Maybe i was not too much specific last time:
> I have a variable "y" that follows a GARCH(1,1) process. Then, i Gretl i
> garch 1 1 ; y const
> Then i got the result and forecasting the out-of-sample values of y can
> be done in the usual way. However, i'm interested in forecasting the
> out-of-sample variance. I don't know if such a function exists in Gretl.
There is no built-in function to do this, but you can compute a
one-step ahead forecast of the variance from the model data, as
hown in the following example script.
garch 1 1 ; Y
series e = $uhat
series h = $h
dataset addobs 10
a0 = $coeff
a1 = $coeff
b1 = $coeff
series hfc = h
# set future errors to their expectation
e = misszero(e)
# forecast the variance
hfc = a0 + a1 * e(-1)^2 + b1 * hfc(-1)
smpl 1970 ;
print e h hfc --byobs
Dear gretl users:
You might be interested to hear about my new paper entitled "Should
Economists Use Open Source Software for Doing Research?" published
this month in Computational Economics. The paper investigates
econometric software reliability and advocates the use of open source
software by taking gretl as a case study and showing how responsive
and transparent its development process is. I think many people here
might find it an interesting read.
More information and the download link is available here:
I can send a working paper version if you do not have access to the above.
A. Talha Yalta
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
On Wed, 2 Feb 2011, [iso-8859-1] RENIER M�lanie wrote:
> I found that in fact if GRETL says it connect to the data source
> inf1 in Oracle, it does not stay connected to it! Does somebody
> already encounter this problem?
Here is what gretl actually does when you issue the commands
open ... --odbc
to open an ODBC connection, and
data ... --odbc
to retrieve data from such a connection.
1) In response to the "open" command we record the information you
provide (DSN, username and password) and try an SQLConnect. If the
connection fails, we issue an error message and delete the DSN
information. If the connection succeeds, we close the connection
with SQLDisconnect but retain the good DSN information for use
with the "data" command.
2) In response to the "data" command we see if there is a set of
good, stored DSN information (from a successful "open"), and if
so we use SQLConnect, grab the requested data, then do
That is, we don't keep the DB connection open indefinitely, rather
we open it on demand based on verified DSN information. And that
information will stay in place for the duration of a gretl
session, unless it is replaced by a further invocation of
"open ... --odbc".
On the SQLConnect there is a login timeout of 5 seconds, which
seems to be fairly standard. If you have a particularly cranky
DBMS that won't authenticate you within 5 seconds, the "open"
and/or "data" commands will fail.
On Mon, 28 Feb 2011, Desikan Srinivasan wrote:
> Greetings and regards. I have installed the
> gretl-1.9.4-no_sse2.exe and tried to run it. But to my surprise
> it fails to run indicating the same error.
OK, thanks for testing. I'm still working on the assumption that
the new random-number generation code is somehow generating
illegal instructions for the athlon. I've now put up a revised
build, gretl-1.9.4-no_sse2a.exe, at
If that still doesn't work, it's possible that there's something
in the updated GTK library stack, packaged with gretl, that is
choking your system; and I can try a build using an older version
But if this version won't start, can I ask you try a debugging run
and see what you get? To start gretl in debugging mode, create a
desktop shortcut item for gretl, but after the path to
gretlw32 add --debug, for example
"c:\program files\gretl\gretlw32.exe" --debug
You should get a console window with some messages that might help
in diagnosing the problem.
Am 28.02.2011 17:07, schrieb ajzhmkaven(a)hotmail.com:
> I got alpha1=0.21 and alpha2=0.23 using arch command and alpha1=0.41
> and alpha2=0.45 using garch command. Does this look like a error? Or
> I am not using the command correctly?
They certainly look quite different at first glance, but it depends on
the data. Maybe you should provide more details, and possibly even the
data. (To the list please, not in private mail.)
does anyone know why do i get different result from running ARCH (2) and GARCH (0,2), are they not suppose to give the same output? i got different alpha (1) and alpha (2)
i want to use the GARCH command for ARCH (2),because i want to get standardized residual for ARCH(2). And from the command user's guide it says ARCH (1) and GARCH (0,1) are the same thing, but i ran both but they are giving me different results. anyone know why? please
On Mon, 28 Feb 2011, Desikan Srinivasan wrote:
> I have first unstalled the previouse version and installed the
> latest release of Gretl. But the error persists. I am using
> windows XP Home SP3. AMD Athlon(tm) XP 1800+processor...
Ah, that's it, thanks for the details. Your processor does not
support the SSE2 instruction set. I've now made a non-SSE2
build of gretl for Windows, gretl-1.9.4-no_sse2.exe. You can
find it at
Could you tell us if this works for you? Thanks.
Dear at Gretl community,
I have installed the latest release of Grelt 1.9.4. After installing , I
tried to run the program (GUI Mode). An error infromation appeared that
Greltw32.exe encountered an error. Kindly look into it.