I wanted to just adjust the mentioned gretl_install.exe size of '9MB' to
'12MB', but I'm not so sure about the way the html files are handled in
cvs. I would have edited 'doc/website/template/win32_pat.html', would
that have been correct?
With current cvs and --enable-build-doc I get the following error with
! LaTeX Error: Command \textcurrency unavailable in encoding T1.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
'März' is German for 'March', the only month with non-ascii characters
in German (well actually only in DE_de, because in DE_at they use
'Jänner' for January instead of 'Januar' -- not sure if you really
wanted to know that though...).
Sven Schreiber schrieb:
> Henrique Andrade schrieb:
>> Dear Gretl Community,
>> I have a question about how Gretl calculates the VAR impulse-responses.
>> Although Gretl says that an one-standard error shock is used in the
>> calculations I can't confirm this, once another value for the standard
>> error is given in the estimation results. To illustrate this I will give
>> an example:
>> open australia.gdt
>> "Modelo 1" <- var 1 le lpus lpau --impulse-responses
>> The standard-error of the "Equation 1" (le) is 0.048110, but the
>> impulse-response uses 0.046827 as the standard-error. I did the same
>> estimation using EViews and, according to that software, 0.046827 is the
>> standard-error with degrees of freedom correction and 0.046827 is the
>> standard-error without degrees of freedom correction.
> Exactly, so you answered the question yourself. I tend to agree that the
> displayed standard error should be used, and then this would be a small
> bug. (there were some changes with VARs and dof-corrections recently,
> cf. the accessors $xtxinv, $sigma, and I guess that what you saw was on
> oversight -- but maybe I'm wrong and it's done on purpose)
[moving over to devel]
Allin, so do you think this is a bug?
I have a script and a workfile in the same directory (and that directory
is not the CWD or dotdir or anything). The script starts with the open
open ea16_96m1_sven18feb10.gdt --quiet
and after starting gretl everything works fine.
However, when I modify the script a little bit, save it, and then
execute it again, I get an error:
? open ea16_96m1_sven18feb10.gdt --quiet
Fehler bei Skriptausführung: Stopp
Restarting gretl cures the (apparently reproducible) issue.
I am a Linux packager for RPM and DEB based systems and I also teach
statistics. I stopped in to your web page to experiment with gretl.
I became curious to know why the gretl packages for Ubuntu/Debian are
lagging behind the times. The repositories seem stalled at 1.8.1 and I
got interested in building an up-to-date deb for gretl-1.8.7. I
adapted Dirk Eddelbuettel's debian setup from the gretl-1.8.1 package
build, but the package build failed when it got to the installation of
a script called gretl-config. In gretl-1.8.1, I find there is a
gretl-config that is generated by the configure script and the debian
package libgretl1-dev includes it. But in 1.8.7, the configure script
no longer generates gretl-config.
It is a bit confusing trying to track the changes through gretl-1.8.1
through 1.8.7. The gretl Changelog does not mention it. In 1.8.7,
there are still some (vestitgial?) references to gretl-config in
Makefile.in and gretl.m4. But no gretl-config.in exists.
I compared the RPMs for these versions of gretl and they do include
the manpage for gretl-config, but they do not include gretl-config
itself(!?!?). Unlike the debian packaging, I don't find a gretl-devel
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
the following mini-script:
ols LRM const LRY IBO IDE
b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
? b[LRY]*b[IBO] - 2*b[IDE]*b[LRY] = 0
? end restrict
b[LRY] - 2*b[IDE] = 0
I have now learned how to formulate nonlinear restrictions, so I know
the above is wrong, but I still think the
parsing is problematic. (Should throw an error instead.)
Also, I think it's a natural feature request to make the formulation of
nonlinear restrictions more intuitive. (I know they are a recent
addition and I'm grateful that it's possible at all, so I'm not saying
that it's urgent. But I guess I will put it in the feature request
tracker because of that.)
auto-indentation of scripts doesn't seem to work properly for blocks like
catch nls ...
catch gmm ..
Is this actually the suggested formatting of using catch here? Or rather:
the following keywords aren't syntax-colored.
Also I wonder whether '$' could be colored as well; I think it would be
useful, but I'm not sure right now whether there would be unwanted side