Gretl project on the launchpad
by Ivan Sopov
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,
etc.
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
question here:
https://answers.edge.launchpad.net/launchpad
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
http://lists.wfu.edu/pipermail/gretl-devel/2009-November/002171.html
12 years, 11 months
gretl and openmp
by Allin Cottrell
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
limited).
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
http://ricardo.ecn.wfu.edu/~cottrell/tmp/gretl_speed.html
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.
Allin
14 years, 2 months
Re: [Gretl-devel] Odd Behavior with the "append" Command
by Allin Cottrell
On Thu, 28 Oct 2010, Henrique Andrade wrote:
> Dear Ignacio,
>
> At first I would like to thank you for your answer. The data I'd sent is
> only an illustrative example of a potential problem. I think it would be
> better if Gretl shows an error message instead of appending the data
> with incorrect dates.
>
> In my humble opinion the best solution would be the correct recognition
> of the dates of the series "incomplete", with Gretl inserting NAs in the
> period 01/07/2008 to 31/07/2008.
I've now tried to do that in CVS. The problem you found is
specific to daily data, in which missing observations have been
"suppressed" rather than entered as such -- but I think this
should now work.
Allin
14 years, 10 months
Odd Behavior with the "append" Command
by Henrique Andrade
Dear Gretl Team,
Today I'd tried to use the "append" command to add a new series to my
session. The series start at 2008/06/04 and end at 2010/10/19. They are
the same, with the exception that the second one, called "ìncompleto",
does not have the observations from July 2008 (more exactly, from
01/07/2008 to 31/07/2008).
Please take a look at the following commads:
open completo.gdt
append incompleto.gdt
The sequence above gives me a very odd result. Originally, both the series
end in 2010/10/19, but after the "append" command, the series "incompleto"
is ending at a different date: 2010/09/16.
I hope I was clear enough. Sometimes English language is hard for me :-(.
Best regards,
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
14 years, 10 months
new dpanel command
by Allin Cottrell
Hello all,
Apologies to those of you who get this message twice. But Jack and
I having been working (on and off) since June on a new dynamic
panel-data estimation command, "dpanel", which we are now ready to
unveil. It's documented in dpanel.pdf at
http://sourceforge.net/projects/gretl/files/manual/
We think it's a pretty nice implementation of the GMM-DIF
(Arellano-Bond) and GMM-SYS (Blundell-Bond) estimators, but we'd
be very grateful to get any feedback you may have before we put
out a release in which this command is truly visible (it has been
there "secretly" for a while now).
Since we have a full ChangeLog, ideally we'd like to make a new
release next week. If you can spare some time to test dpanel
before then, that would be great. We're looking for any
show-stopping bugs and/or severe differences over what the default
behaviour of this command should be. We have tried to build in
what we take to be sensible defaults so that "standard"
invocations of the command are short and sweet, while more complex
or non-standard uses are also supported.
Note that at this point there's no GUI access to dpanel, it's a
script-only thing. If we have the script command right, a
graphical interface may follow.
[Footnote: Sven Schrieber suggested that this command might better
be named "dynpanel", and we invited votes on this on the
gretl-devel list. But, the vote being indecisive (only Ignacio
Diaz-Emparanza put in an opinion), I'm afraid that the preference
of Jack and myself for brevity has prevailed!]
Allin
--
Allin Cottrell
Department of Economics
Wake Forest University
14 years, 10 months
int argument pointer
by Sven Schreiber
Hi,
currently an argument pointer for a function doesn't work if the type is
'int'. For illustration run the following:
<script>
function void check1(scalar *a)
print a
end function
function void check2(int a)
print a
end function
function void check3(int *a)
print a
end function
</script>
which gives for me:
? function void check1(scalar *a)
> print a
> end function
? function void check2(int a)
> print a
> end function
? function void check3(int *a)
Unrecognized data type 'int *'
I guess that's a bug since I don't see any reason why it should work
with 'scalar' but not with 'int'?
thanks,
sven
14 years, 10 months
Re: [Gretl-devel] a small bug
by Allin Cottrell
On Tue, 19 Oct 2010, Sven Schreiber wrote:
> Am 19.10.2010 08:34, schrieb Talha Yalta:
> > I got this weird output for the Portmanteau test...
>
> Maybe it's related to 7 lags and 20 obs, which may run already into
> d.o.f. problems? Of course the behavior is still a bug.
Thanks for the report. This is now fixed in CVS.
Allin
14 years, 10 months
a small bug
by Talha Yalta
I got this weird output for the Portmanteau test. Maybe worth a check?
Talha
VAR system, lag order 7
OLS estimates, observations 1989-2008 (T = 20)
Log-likelihood = 189.21287
Determinant of covariance matrix = 2.0779778e-011
AIC = -15.3213
BIC = -13.5290
HQC = -14.9714
Portmanteau test: LB(5) = 76.5391, df = -8
[179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000]
Equation 1: LN_GDP
...
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
14 years, 10 months
Re: [Gretl-devel] Opening data from web
by Allin Cottrell
On Mon, 18 Oct 2010, Henrique Andrade wrote:
> Today I'd started to test the new functionality: The "open"
> command capacity to get data files from web. It is really great!
>
> I'd tried these commands:
>
> open
> http://research.stlouisfed.org/fred2/series/INDPRO/downloaddata/INDPRO.xl...
If you download the file in question and try opening it in gretl
as specified, you get:
"This file is not an 'OLE' file -- it may be too old for gretl to
read." It's some sort of ancient Microsoft format. (Thanks, St
Louis Fed!). The "file" command on Ubuntu 10.04 says:
"INDPRO.xls: CDF V2 Document, corrupt: Cannot read summary info"
> open
> http://research.stlouisfed.org/fred2/series/INDPRO/downloaddata/INDPRO.tx...
Sorry, --rowoffset=XX is not available for plain text files, only
for spreadsheets.
> open
> http://research.stlouisfed.org/fred2/series/INDPRO/downloaddata/INDPRO.csv
>
> But only the last one (.csv) had returned the values. Is there anything
> wrong with the others?
Noted above. Try, for example, stata ".dta" files available via
the web, these should work OK.
Allin Cottrell
14 years, 10 months
