Hi, I'm getting reproducible crashes of the latest snapshot on windows
whenever I try to open the Data menu.
However, this only happens with the German translation loaded, so I
suppose it could be my fault as the current German translator ;-)
I could need some help investigating the causes though...
Any advice is appreciated,
OK, there's now a snapshot with some of the new features we've been
discussing. It has matrix methods, 15-character variable names, and
a new lag-selection dialog box.
This version still needs to have the bugs shaken out of it, so I
wouldn't recommend feeding it to students yet. It is available at
this URL only:
Department of Economics
Wake Forest University, NC
> On Tue, 31 Jan 2006, John Paravantis wrote:
>> Then try to run an ARMA(1,1): you get a dialog that "The
>> convergence criterion is not met". Unfortunately, it is possible to
fiddle with the convergence criterios (# of iterations) on the ARMA
[ ... ]
> I'm not sure precisely what feature of the data or gretl's methods is
responsible for the non-convergence in your first model.
> Perhaps Jack will have an idea on that. But note that in gretl you have
the option of using X-12-ARIMA for ARMA estimation, and in this case it
will produce estimates for you.
The issue we have here is very similar to the GARCH case that was
discussed here about 3 weeks ago (see
The "ARMA(1,1)--no constant" model has a likelihood function that, with
this dataset, appears to have no maximum inside the admissible parameter
region. I tried the same model with several packages: all of them report
For example, R's "tseries" package yields
ar1 ma1 intercept
0.6318 -1.0000 0.0440
s.e. 0.1522 0.1102 0.0129
And clearly the idea here is to stop when the algorithm takes you to a
noninvertible MA structure. Ox arfima package gives:
Coefficient Std.Error t-value t-prob
AR-1 0.648324 0.1489 4.36 0.000
MA-1 -1.000000 0.1365 -7.32 0.000
which is very close to R. Eviews (ugh!) gives
AR(1) 0.460374 0.643653 0.715253 0.4804
MA(1) -0.674092 0.551803 -1.221617 0.2320
which is rather strange, considering that the score vector at that point
is not zero (but Eviews in not renowned for its numerical strength).
What *we* do here is simply give up. Actually, those who use linux will
perhaps see the message
MA root 0 = 0.999999
arma: MA estimate(s) out of bounds
bhhh_max: crit = 8.44786e-06, tol = 1e-06, err = 40
arma: bhhh_max returned 40
but that is issued to stderr, not to the main output (Allin, maybe we
ought to redirect this?)
As Ricardo pointed out, the trouble here is probably overdifferencing,
which induces a unit root in the MA part. If you try working with 1st
differences instead things are much much better. Try this:
genr ccars = cum(cars)
arma 1 1 ; ccars
Model 5: ARMA estimates using the 30 observations 1971-2000
Dependent variable: ccars
VARIABLE COEFFICIENT STDERROR T STAT P-VALUE
const 0.123980 0.139820 0.887 0.38279
ccars(-1) 0.863621 0.230057 3.754 0.00081 ***
e(-1) -0.0827397 0.400739 -0.206 0.83792
If you get an adequate ARMA representation for "ccars", obviously any ARMA
representation for "cars" contains a unit root in the MA part, due to
excessive differencing. Hence the numerical problems.
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Methinks I found a bug in ARMA.
Copy/paste the following data into a gretl column (possibly pasting into
Word and ALT-copying and pasting the column into Excel):
(They are 2nd differences of car ownership per 100 people in Greece,
from 1970 to 2000 appr.)
Then try to run an ARMA(1,1): you get a dialog that "The convergence
criterion is not met". Unfortunately, it is possible to fiddle with the
convergence criterios (# of iterations) on the ARMA dialog box!
Here comes worse. Try to estimate an ARMA(0,1) WITHOUT THE CONSTANT: you
get an "out of memory error"!
Incidentally, these estimate ok in Statgraphics 5.1.
BTW thanks to all for your kind responses to my graph querry:
- Peter (of Colorado), many thanks for your tip -- I would rather not go
through the PNG format because unlike vector graphics it deteriorates
when zoomed and is usually not accepted by research journals.
- Jean, your appropriate reference to Gnumeric made me delve deeper into
Excel 2003 (yuck!) only to find out that the reason I do not get the
format confirmation dialog anymore is that Excel 2003 has now a separate
menu (Data>Import External Data...) that imports other formats! Using
that menu worked fine!
Warmest regards to all,
University of Piraues
PS I am mailing a separate gretl file with the above data to Allin (I
cannot attach files to the user forum address, can I?)
When I select "Model data" > "Forecasts ..." in, say, the OLS platform,
gretl graphs and tabulates forecasts and confidence intervals.
Unfortunately forecasts CANNOT BE SAVED (so I usually type them in
manually). Would you consider adding this functionality?
Another somewhat related issue. Say I right-click on a variable and
select "Display values" - an output window opens and the values are
nicely tabulated. Now, if I click the copy icon, I can choose among "RTF
(MS Word)", "Table (MS Word)", CSV (Spreadsheet)" and "plain text";
then, depending on my previous choice, I may be presented with a final
dialog in which I may choose among comma, space and tab.
Well, THESE DON'T WORK -- no matter which one I select, the clipboard
always contains TEXT.
This, I think, is an IMPORTANT issue because it hinders copying and
pasting columns of data in Excel; if you copy multiple columns and past
them in Excel, they end up in ONE Excel column and data look like (ALL
IN ONE EXCEL COLUMN):
Excel 2003 does NOT seem to be doing the translation correctly. Is this
a gretl issue or am I missing something?
Regards from Greece
University of Piraeus
>>When I select "Model data" > "Forecasts ..." in, say, the OLS platform,
>>gretl graphs and tabulates forecasts and confidence intervals.
>>Unfortunately forecasts CANNOT BE SAVED (so I usually type them in
>>manually). Would you consider adding this functionality?
>Don't you see the forecasts in a window equipped with Save, Print
>and Copy buttons?
I DO -- what I meant is that it would be nice if I could SAVE the
forecasts into a gretl data column, i.e. by choosing
"Model data" > "Add to data set"
where one can add to data set fits, residuals etc but NOT forecasts.
Alin and community,
When a graph is copied to the clipboard and pasted to, say, Word, it has
a very wide TOP and RIGHT margin.
Usually, I have to crop about 3.5 cm from the top margin and 5 cm from
the right margin to make the white space around the graph appear
Can you correct this?
University of Piraeus
-----BEGIN PGP SIGNED MESSAGE-----
I'm using the latest Windows snapshot, and I did a simple test to
check how things are about the decimal point vs decimal comma
notation. So numbers must be entered with decimal point, but the
outputs are with decimal commas; is this the final decision?
About difficulties on handling scripts saved by users using decimal
commas, should it be established that "session files should always be
saved with decimal points, and at the moment of loading the session
the numbers are filtered to reflect user preference.", this way the
interactive environment would use user preference for inputting numbers.
Or alternatively, for readability of the session file, it stays as it
was saved, only that on the first(s) line(s) should appear a special
gretl directive, like for instance:
# gretl::list_separator=";" # this way a function call
would be: function_name( x ; y )
or a single directive, like;
This way, by default, if no directives, no need for more processing.
And if directives match current user options, no need to filter the
numbers. So a user reading a session file would know how the numbers
are represented even if not using Gretl.
What you think about this?
My test output was obtained using Windows version, with the "use
locale decimal setting" checked (locale is Portuguese settings).
gretl console: type 'help' for a list of commands
? genr myvariable=1.2345678
Generated scalar myvariable (ID 5) = 1,23457
? print myvariable
myvariable = 1,23457
? genr myvariable=1,2345678
Syntax error in command line
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Most of the time, I fail to reconstitute the sessions I have saved. I
sometimes manage to open them, but I don't understand what is different from
when I can't. Am I missing something about it ?
I would like to ask a question on internal variables in gretl. From
the command reference I have learned that one can access the fitted
values from the mast regression command using an internal variable
called $yhat. So, after running a probit regression one can obtain the
predicted probabilities via $yhat. I would like to know if there is a
variable that stores the values of the linear predictor. Formally, in
addition to obtaining F(xb), I would also like to obtain xb, for
non-linear models such as probit, logit or poisson. In probit
regression, the linear predictor will e.g. be useful for computing
Mills' ratio or slopes (other than those computed by gretl).
I have another slightly related question. Under the genr entry, the
gretl command reference tells that one can access estimated
coefficients using coeff(var). I tried the following using one of
Wooldridge's sample datasets:
ols re78 const train
genr pre = $yhat
genr mycoeff = coeff(train)
The script runs fine until the last line. There it stops and tells me:
? genr mycoeff = coeff(train)
Syntax error in genr formula
Error executing script: halting
> genr mycoeff = coeff(train)
I couldn't find any hints on a potential mistake in the documentation.
Could anyone tell me what's wrong here? I am using gretl 1.5.0 (build
date 01/17/2006) on Windows XP.
Thanks for your attention.