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.
On Fri, 10 Dec 2010, Sven Schreiber wrote:
> Am 10.12.2010 19:41, schrieb Henrique Andrade:
> > Em 10 de dezembro de 2010 Allin Cottrell <cottrell(a)wfu.edu
> > It happens because if you were to delete those variables this
> > would result in the re-numbering of several variables that appear
> > as dependent or as regressors in saved models, which would totally
> > confuse gretl.
> > Perhaps the error message should be adjusted in this case: saying
> > that the variable is "in use" is not quite accurate. But the
> > substantive point is correct: you really can't delete those series
> > without destroying your session file.
> > Dear Allin,
> > In my humble opinion this behavior doesn't look good. Suppose
> hm, I think I'm sharing Henrique's view here. I certainly don't want to
> confuse gretl (meaning: I understand that this is stuff that cannot be
> changed quickly or easily), but in principle I think the external
> numbering of variables shouldn't cause these kind of constraints.
> Which leads me to ask: why actually do the variables have to be
> renumbered after deleting something? Couldn't the numbers be simply
> non-contiguous? Alternatively, maybe (in the longer term) there should
> be a mapping from an internal immutable id number to the externally
> visible numbering of the variables.
The ID number of a series in gretl is simply the 0-based position
of that series in a two-dimensional array of double-precision
values. If a given series is deleted, it's inevitable that
higher-numbered series will be relocated and hence renumbered --
unless we were to permit holes in the dataset, which would be a
Neither IMO, does it make any sense to keep two sets of books, one
recording where variables actually are and another for some sort
of cosmetic purpose; the mapping between these two would be an
obvious source of errors, crashes and so on.
The only way that I can see to permit deletion of lower-numbered
series when higher-numbered ones are "in use" is to crawl all over
the session and adjust all references to series by ID number,
wherever they are found (notably in saved models but also
elsewhere). This is doable in principle, but is a likely source of
I just encountered a case where a script with some 'tsls' estimates
would suddenly cause an (false) error "order criterion not met, you need
at least 4 more instruments".
Restarting gretl and running the same script solved the problem, so
there must be some bug with instrument counting.
this is gretl cvs from Nov 26th (so old already...)
On Tue, 21 Dec 2010, Sven Schreiber wrote:
> I just tried to do NLS w/o initializing the parameters -- the error
> message was not informative ("wrong data type"). If I use "catch", I get
> an even stranger message: "no regression function is given".
Sample script, please.
I've tried modifying/breaking the file ects_nls.inp, supplied with
gretl, in two different ways:
* Remove the definition of the parameter "alpha" altogether --
Error message: The symbol 'alpha' is undefined
* Give a bare declaration of alpha, no initialization --
Error message: Data error
On Wed, 22 Dec 2010, Sven Schreiber wrote:
> I don't remember if there was a discussion on this (Jack's wiki?), but
> maybe 'hsk' is a candidate for deprecation, in favor of 'ols .. --hsk'
> or something like that?
> Haven't thought this through, but it strikes me as quite special to have
> its own command.
I don't have strong feelings about "hsk", but I don't think an
option to "ols" works as an alternative, since it's not a case of
OLS. We consolidated the FGLS variants for AR(1) estimation, which
used to have their own commands at one time, under a common "ar1"
command, but I don't see a "natural" place to consolidate hsk.
[moved to gretl-devel]
I don't remember if there was a discussion on this (Jack's wiki?), but
maybe 'hsk' is a candidate for deprecation, in favor of 'ols .. --hsk'
or something like that?
Haven't thought this through, but it strikes me as quite special to have
its own command.
Am 22.12.2010 13:42, schrieb Allin Cottrell:
> On Wed, 22 Dec 2010, yinung at Gmail wrote:
>> I cannot replicate the FGLS estimation results as shown in
>> Example 8.7 (demand for cigarettes) of Wooldridge's
>> "Introductory Econometrics" (I am using the 3rd edition, on page
>> I use the default FGLS function under the the main menu
>> \Model\Other linear models\Heteroscedasticity corrected. with
>> the datafile as attached. Or run the following script command
>> hsk cigs const lincome cigpric educ age agesq restaurn
>> The result is different from the one in Wooldridge's textbook.
>> Do I use the wrong model?
> Probably not, if what you want is WLS to take into account
> estimated heteroskedasticity. However, you should read the help
> for "hsk" carefully to see what gretl is doing. I don't have
> Wooldridge's text to hand, but maybe he's not using a log
> transformation for the squared residuals in the auxiliary
> regression, as gretl does?
> Allin Cottrell
> Gretl-users mailing list
On Tue, 21 Dec 2010, Marco Lechner - FOSSGIS e.V. wrote:
> do I have to recode all my non-numeric columns like that? can't gretl
> handle non-numeric values?
If you save your spreadsheet data as comma-separated values, gretl
will convert the non-numerical columns to numerical values on
import (and will write out a "string table" showing the mapping
from strings to values).
i'm new to gretl and running into a problem importing a xls-spreadsheet:
the spreadsheet has a column "sex" with values "m" or "f" and gretl
throws an error telling me that she expected numerical data for this
column, but found a string (which is correct, because I have values of
"m" and "f". how to import this into gretl?
the same error occurs when using openoffice calc.
gretl 1.8.7 running on ubuntu 10.10
I just tried to do NLS w/o initializing the parameters -- the error
message was not informative ("wrong data type"). If I use "catch", I get
an even stranger message: "no regression function is given".