Hello, gretl developers.
I'm trying to start a translation of help files into russian on
launchpad.net as it seems to be the most suitable tool to participate
for all familiars with econometrics but not with gettext, linux. cvs,
The problem is that there is already a project for gretl on launchpad
and it is strongly prohibited to start more than one project for a
single program. I cannot contact with Constantine Tsardounis for about
a month, so I think it is time to re-assign that project to someone
else. On the irc-channel of launchpad I was told that
Our admins can re-assign the project to new owners but we'd prefer to
hear from the upstream owners. can you get one of them to submit a
But if nobody from main developers wants to register and do something
at launchpad it is possible to assign this function to me and in that
case a letter in this list will probably be enough.
I have prepared a .po-file for genr_funcs.xml and gretl_commands.xml
with the help of po4a utility and got 1511 strings for translation
(strings a rather big).
Good luck, Ivan Sopov.
P.S. My previous letter about using launchpad for translation is
As some of you know, we're currently experimenting with openmp in
gretl. When building from CVS, use of openmp is the default (if
openmp is supported on the host) unless you pass the option
--disable-openmp to the configure script. In addition the current
snapshots for Windows and OS X are built with openmp support
(using gcc 4.4.3 and gcc 4.2.4 respectively).
This note is just to inform you about the state of play, and to
invite submission of test results if people would like to do that.
Right now, we use openmp only for gretl's native matrix
multiplication. So it'll get used (assuming you have at least two
cores) if you do matrix multiplication in a script, or call a
function that does matrix multiplication (such as qform), or use a
built-in command that happens to call matrix multiplication. If we
decide it's a good idea, we could use openmp directives in other
gretl code (but as along as we rely on lapack for much of our
number-crunching, and as long as lapack is not available in a
parallelized form, the scope for threading will remain somewhat
In a typical current use situation, with gretl running on a
dual-core machine where there's little other demand being placed
on the processors, the asymptotic speed-up from openmp should be
close to a factor of two. However, it takes a big calculation to
get close to the asymptote, and we've found that with small to
moderate sized matrices the overhead from starting and stopping
threads dominates, producing a slowdown relative to serial code.
This is similar to what we found with regard to the ATLAS
optimized blas; see
Anyway, in case anyone would like to test I'm attaching a matrix
multiplication script that Jack wrote. Right now this is mostly
useful for people building gretl from source, since you want to
run timings both with and without MP, which requires rebuilding.
But if you're currently using a snapshot from before yesterday
(build date 2010-03-21 or earlier) you could run the script, then
download a current snapshot and run it again.
Found after OLS, in a model Window, heterocedasticy test between groups:
Pooled error variance
~/gretl$ grep -R "Pooled error variance" --include=*.c ./
./lib/src/gretl_panel.c: pprintf(prn, "Pooled error variance = %g\n\n",
I've just committed some changes (not many) to gretl.pot in
preparation for putting out gretl 1.9.3.
I've fixed a couple of nasty bugs lately (a crash in "quantreg",
and something that prevents gretl from displaying graphs on some
Windows systems) and I'm inclined to push these fixes into a
release sooner rather than later.
On Wed, 24 Nov 2010, Sven Schreiber wrote:
> a UI minor issue:
> In the help menu there are two "command ref" entries
> ("Befehlsdokumentation" in German), only the experienced user knows from
> the icons that one is online help, the other a pdf file...
What platform is this on? There are little icons to distinguish
the two menu items, but these may be suppressed by some desktop
once you asked for suggestions for the user manual. I guess it's pretty
obvious, but today I noticed that there is no explanation of the
simultaneous equation systems methods.
I know I know, I should write it myself, and in principle I would like
to. Realistically not before March, however. BTW, I think the gretl
conference is a good thing also in terms of a mental deadline, it's
better to say "it should be finished before the conference" instead of
"it's long overdue, it would really be good to have it" which basically
means: it can wait some more.
a UI minor issue:
In the help menu there are two "command ref" entries
("Befehlsdokumentation" in German), only the experienced user knows from
the icons that one is online help, the other a pdf file. I suggest to
make this clearer, e.g. by naming them accordingly with "built-in" and
"pdf" or similar. Maybe also regrouping? (although I see the logic of
putting the pdf stuff together)
On Mon, 15 Nov 2010, Lee Adkins wrote:
> Hmmmm ... I think what I may do is create the coefficient matrices R, r for
> the linear combination Rb-r and just use the matrix language to compute the
> restricted least squares estimator. Given that I'm going to try a simple
> simulation for it I'm thinking the writing and reading to files would slow
> things down a lot.
Yes, that makes sense. However, available for testing: in CVS and
snapshots I've now enabled the --full option to the "restrict"
command for single-equation OLS.
ols 1 0 2 3 4
b3 - b4 = 0
end restrict --full
matrix b = $coeff
Append --quiet (or --silent) if you're not interested in the
printout of the restricted estimates.
On Mon, 15 Nov 2010, Lee Adkins wrote:
> Is there an accessor for restricted estimates after a restrict
> statement? After ols the restricted regression runs by default,
> but I can't figure out how to access the restricted estimates.
> BTW, my goal here is to shrink unrestricted estimates toward the
Right now there's no such accessor. One possibility would be to
generalize the "--full" option to restrict, which is currently
available only for VECMs. This replaces the "last model" with the
restricted estimates, so that the $coeff accessor can be used.
At present if you want to get the restricted estimates from OLS
programmatically you'd have to use gretl's string-handling
functions (which would get you the coefficients to 6 significant
digits), as in:
ols 1 0 2 3 4
outfile restrict.txt --write
b3 - b4 = 0
string s = readfile("restrict.txt")
matrix b = zeros(4,1)
loop i=1..4 -q
if (i == 1)
s = strstr(s, "const")
s = strstr(s, "\n") + 3
s = strstr(s, " ")
sscanf(s, "%lf", &bi)
b[i] = bi
printf "\n%10.6g\n", b
Is there an accessor for restricted estimates after a restrict statement?
After ols the restricted regression runs by default, but I can't figure out
how to access the restricted estimates. BTW, my goal here is to shrink
unrestricted estimates toward the restricted.
Professor of Economics