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, 6 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
13 years, 10 months
gretl and openmp, again
by Allin Cottrell
I have reversed the configure option when building gretl from CVS:
if you want openmp support, please use
--enable-openmp
In addition I'm omitting openmp support from the snapshot builds
for Windows and OS X.
This is surely something we'll want to come back to, but for now,
in most practical-use cases, openmp slows things down a little
while adding bulk to the pre-compiled packages.
Allin
15 years
Gretl VAR Improvements
by Henrique Andrade
Dear Gretl Team,
I would like to suggest some improvements (I think ;-)) to the VAR model
window. My aim goal is to make VAR model window more close to OLS model
window in terms of "easiness of use". Additionally, it would be a good
change for Gretl 2.0. Some of the suggestions have been inspired by EViews.
(1) Impulse-response: I think it could be useful if we had more options
regarding to the impulses. EViews has the option "impulse definition" where
we can choose the decomposition method (Residual - one unit; residual - one
std. deviation; Cholesky - dof adjusted; Cholesky - no dof adjustment;
generalized impulses; structural decomposition; and user specified.
(2) Impulse-response and variance decomposition: It would be great if we had
the option "Cholesky ordering" (I know we can choose this before the
estimation, but I think this is not so good).
(3) Granger causality test: I think the test should be more explicit, just
as tests of OLS are (ie, the results should only appear when it was
requested). The unaware user may not realize that the results that appear
below the estimated equations are nothing more than the Granger causality
test. Thus, after the VAR estimation, we could select "Tests -> Granger
Causality Test" and the following result would appear:
Granger causality test -
Null hypothesis: "v1" does not cause "v2"
Test statistic: F(1, 72) = 1,6655
with p-value = P(F(1, 72) > 1,6655) = 0,2010
I really don't know how difficult are this (in terms of code), but I think
it would be very nice ;)
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
15 years
translation questions
by Sven Schreiber
Hi,
some questions on the meaning/context of translatable terms:
* NegBin 2
* NegBin 1
* Negative Binomial
* Negative Binomial 1
(what's with the numbering; and should they be translated at all?)
* NBER recessions
(why is this in the .po files? NBER hardcoded into gretl?)
* Overdispersion test
(what are the test details, where do I find it in the menus?)
thanks,
sven
15 years, 1 month
GUI Behavior Feedback
by Talha Yalta
Today, I did an oral quiz to my econometrics students (about 50 of
them) by asking to perform a randomly selected task using gretl. This
took a couple of hours and went pretty well but I also had a small
feedback regarding the GUI behavior:
I noticed that clearing the data set or opening or creating a new data
or a session properly closes all the existing windows, which is nice.
The various statistical tables, distribution graphs etc windows in the
tools menu, however, remain open. I understand that these are not to
do with the data but still I think it would be a bit better if those
are closed also, with the expectation that the user is probably
wanting to starting a fresh analysis so everything should go to the
initial case where there is only the gretl main window.
I don't know if there is a case for keeping these particular windows
open but if everyone is indifferent, IMHO closing all windows in such
cases works just a bit better.
Cheers
Talha
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
15 years, 1 month
oxgauss
by Sven Schreiber
Hi,
I would like to ask whether it's worthwhile to enable the OxGauss
functionality in combination with gretl's Ox support. (OxGauss means
that Ox can run many existing Gauss programs.) It seems to me that basic
support would be relatively simple, since only a -g switch is needed; so
for running a Gauss program 'mygauss.prg' gretl would need to call:
<path/to/>oxl -g mygauss.prg
(instead of '<path/to/>oxl myox.ox')
I guess a further issue would be how to pass matrices to what would then
be Gauss code, but note that even without it I think it would already be
useful to be able to do:
<gretl-script>
store @dotdir/mydata.dat --jmulti
# jmulti's format should be same as Gauss (?)
foreign language=OxGauss
T = 100; # ugly hardcoding, but not the point here
k = 2;
load datamatrix[T,2] = mydata.dat; # hope OxGauss would find this
print "yeah";
end foreign
</gretl-script>
In terms of user interface I tend to think that no separate script class
for Gauss code (executed via OxGauss) should be introduced, since Gauss
in my view is a little obsolete. But maybe opinions differ on that.
BTW, the background in my case is to build wrappers around the break
test codes of Qu&Perron (Econometrica 2007) or Bai&Perron etc. which are
only available in Gauss, a little lengthy, and also I'm not sure whether
their license would allow porting.
thanks,
sven
15 years, 1 month
Problem compiling and running Gretl CVS in Mac OS X 10.6
by Berend Hasselman
I have compiled the latest Gretl from CVS on Mac OS X 10.6.2 using the GTK+ 2.14.3 framework from the R project.
I also use private builds of libfftw2, libgmp, libmpfr, libreadline.
The compile proceeds without error.
I create a Mac .app using platypus.
This works fine with Gretl 1.8.7.
However, running my bold of cvs gretl results in the following error on startup (and gretl quits):
-----------------------------------------------------------------------------------------------
dyld: lazy symbol binding failed: Symbol not found: _omp_get_wtime
Referenced from: /Users/berendhasselman/tmp/gretl-image/Gretl.app/Contents/Resources/bin/../lib/libgretl-1.0.0.dylib
Expected in: flat namespace
dyld: Symbol not found: _omp_get_wtime
Referenced from: /Users/berendhasselman/tmp/gretl-image/Gretl.app/Contents/Resources/bin/../lib/libgretl-1.0.0.dylib
Expected in: flat namespace
Trace/BPT trap
-----------------------------------------------------------------------------------------------
I have also tried the option --disable-openmp of configure.
Same result.
This must have something to do with the recent changes wrt openmp.
What's going on and what could be done about this (if at all possible)?
Berend
15 years, 1 month
bug/requests collection
by Sven Schreiber
Hi,
the list has been busy recently with bug reports (and also some feature
requests), and it's absolutely understandable that not all bugs could be
fixed right away. (It still continues to amaze me that a sizeable
proportion of bug reports are addressed immediately by Allin.) So here's
a list of what may still be open issues. After clarification and
discussion I will transfer the remainder of this list into the bug
tracker and feature requests databases.
thanks,
sven
--------
* icon for "code view" in the function package list window: change from
cogwheel to something more intuitive
* icon of function package list window (and others) in taskbar is only
generic (non-gretl) on linux (self-compiled cvs) -- actually, i don't
get any icons for menu items on linux (as opposed to windows), I suppose
that's a bug of my setup?
* the help about invcdf() says P(X<x), but shouldn't it be P(X<=x)?
* the command 'include myfilenamewith.dots' fails even if
'myfilenamewith.dots.inp' exists (and is in the right place/dir),
apparently because gretl interprets .dots as a filename extension
* variable is being treated as discrete should be made optional rather
than automatic (I thought it was already the case after a discussion
some months/years ago)
* function namespace bug; see
http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html
* Estimating one equation with 7 variables and 3 lags with OLS produces
a glitch with one of the variable names: Instead of 'Yield_10yr_1' the
name 'd_Yield_10yr' is printed. (Maybe it has to do with the
underscores in the name?)
* The command 'rmplot' is defined only for the GUI. I (=Ignacio) think
it would be very good if we could use it also in scripts.
* script accessors ($test etc.) for bootstrapped test results
* the exogenous variables in a Johansen test setting aren't reported;
and a warning should be printed that the critical values and p-values
are in general only appropriate in the case without exogenous variables
15 years, 1 month