I ran ./gretl.sh and I was able to solve the probelm. I set the
"export GDK...." line to 0 as described in the readme file and now
gretl works perfectly! I didn't pay attention to this hint first
because I thought it was just something like a "cosmetic" thing...
thanks a bunch for your help!
I have the following problem: everytime I try to start gretl I get a
"-192 error: Could not run this script". I already installed the
XCode tools but that didn't help.
I really need gretl to run since the test in my econometrics course
is based on gretl...
Thanks in advance for your help!
We've now (at least temporarily) standardized on PDF and plain text
as the primary formats for the gretl manual (we can make both win32
compiled HTML and gnome HTML/XML, but these formats are were never
properly integrated in terms of searchability and contextualization,
and I really don't have time to work seriously on that).
So I'm now thinking it would be a good idea to distribute the PDF
manual files with gretl. The only problem is that we have four
variants of these files:
* English (US letter paper)
* English (A4 paper)
* Italian (A4)
* Spanish (A4)
I think it would be "bloat" to distribute all of these files with
the gretl package for Windows and the gretl source package (or the
rpm). We're talking about approximately 1 MB per variant. So I'm
looking for clever suggestions. One thought that occurred to me is
to have a "PDF server" (either at Wake Forest University or at
Sourceforge), which would check the IP address of a gretl
installation requesting the manual and try to determine which
variant was most appropriate. Then we could do one download, after
which the relevant manual files would be on the local computer.
Any ideas, either (a) on how exactly to implement the above, or (b)
in the form of better proposals?
As per the discussions here a week or two ago, I have now
restructured the gretl manual into two parts, a Command Reference
and a User's Guide. You'll see this in the next gretl release.
Meantime, for anyone wanting to take a look at the new manual, and
in particular for translators, please see
The file "notes.pdf" explains what's going on; "gretldoc.tgz"
contains the current sources for the manual (for the benefit of
those who want the sources but who don't use CVS); and the
per-language directories -- "en", "es" and "it" -- contain PDF
renditions of the two parts in English, Spanish and Italian.
Now I just have to get the manual up to date with the program!
I'm playing a bit with the NLS command. I looked in the Manual for more
info about the stderr without success. Here my question.
It seems to me that the stderr of the estimates are calculated as
Is that true? Is this the only way implemented?
Angelo Secchi PGP Key ID:EA280337
I'm thinking once again about something that occupies me from time
to time, namely the best source format in which to store the gretl
At present, gretl help is available in three formats:
1) Plain text (called up by the context help buttons in gretl
dialogs, for example).
2) PDF: the whole gretl manual is available as a PDF file.
3) Platform-specific help files. The gretl manual is also available
as a Windows "chm" (Compiled Html) file, and as HTML or XML for
viewing on the gnome desktop.
I'm wondering, how many people use format 3 (Windows or gnome help)?
If the answer turns out to be, hardly any, that might make a
difference to my thinking on the best base format for the manual
Thanks for any observations on this.
On the issue of the gretl manual, I too vote for TWO manuals: a user's
manual AND a reference manual. The latter should thoroughly explain ALL
procedures available in the program.
Of all manual formats I find PDF best (regardless of the source format
that was used to produce PDF). PDF manuals with live links would be great.
Best to all
University of Piraeus
I am not sure if the following is a bug or if it can be avoided, basically I have a gretl script that adds variables (many) to a model. The script then tests the AIC value to determine if the var improved the model. However, I received the following message on a certain variable be omitted from the model:
Null hypothesis: the regression parameters are zero for the variables
Asymptotic test statistic:
Chi-square(2) = 4.69312, with p-value = 0.0956979
Then gretcli had a segmentation fault. The core dump regularly happens with the script on the same data. However, it sometimes does not seg fault with the above message with another model with different data. That is, gretlcli will continue without a seg fault even though the Null Hypothesis messages is produced.
Here is a snip of the script:
genr maxVar = max(ld_ci_15);
genr minVar = min(ld_ci_15);
if maxVar != minVar;
genr aicTmp = $aic;
if aicTmp >= aiken - 1;
genr aiken = aicTmp;
One thing I did notice from the log file is that all other variables actually showed up in the log on "add" and "omit" however the var in question (ld_ci_15) did not(see log below):
? genr maxVar = max(ld_ci_15)
Replaced scalar maxVar (ID 1109) = 1
? genr minVar = min(ld_ci_15)
Replaced scalar minVar (ID 1110) = -1
? add ;
Comparison of Model 1917 and Model 1918:
Of the 2 model selection statistics, 0 have improved.
? genr aicTmp = $aic
Replaced scalar aicTmp (ID 1111) = 991.01
? omit ;
Notice how the variable is not listed in the above snip. The other previous variables do show up with the add and omit.
My question is, is there a way to do a test on a variable to determine if it would produce the message "Null hypothesis: the regression parameters are zero for the variables" prior to adding/omiting to the model? Or is the core dump a bug that can be fixed?