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, 8 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, 11 months
series as special case of lists
by Sven Schreiber
Hi,
here's a RFC or a feature request, in some sense:
Currently a gretl 'list' datatype is strictly different from a 'series'
type it seems. So when a user-written function expects a list, you
cannot pass it a series.
(BTW, it the error message was a little strange: something like "unknown
datatype where list was expected", although gretl should recognize its
own series type?)
But isn't a series really a 1-element list? Wouldn't it actually make
sense to not have a different series datatype, just lists with varying
numbers of elements?
Note that the built-in functions for series already seem to honor this
principle, because they accept both series and list datatypes.
I think it's good to think about this before gretl 2.0...
thanks,
sven
15 years
Marking for Translation
by Henrique Andrade
Dear Developers,
Today I'd found a expression that I think isn't marked for translation. In a
OLS model window
choose File -> View as equation. The expression is "R-squared".
Best regards,
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
15 years
graph export format
by Sven Schreiber
Hi again,
call me a cross-platform nerd, but I really think that gretl should
offer the PDF export of graphs both on Windows and on Linux. (Don't know
the situation on Mac.) The thing is that the same options in gretl's
control dialog produce differently looking graphs in eps and pdf. For
example, the size of the point markers (when linespoints style is
chosen) is quite different. I guess this problem depends on the
so-called gnuplot terminals involved, but IMHO that doesn't mean it's
not a gretl problem as long as gretl chooses gnuplot for graphing.
To put this into the right perspective: it's really nice and smooth to
produce graphs with gretl since the (relatively recent) improvements
like line width factors and so on have taken place. So this whole thing
is of course not a crucial issue, given that it affects only those funny
people using gretl on both platforms.
(I'm not sure right now if there is eps export on Windows --will check
tomorrow-- so if that's the case then in principle it could be argued
that for a cross-platform solution one should be using eps. However, it
seems to me that nowadays pdfLaTeX is generally more popular than
regular LaTeX, so that would suggest to focus on pdf.)
so much for that...
thanks,
sven
15 years
ADF test down
by Sven Schreiber
Hi,
just a presentational issue: when you select the --test-down option for
an ADF test, and it turns out that no lagged differences are retained,
gretl prints out a non-augmented DF test. I have found this confusing
because I was looking for the message how many lags were used in the
equation. Also, arguably allowing for lags which turn out insignificant
is something different from the plain DF test which doesn't allow lags.
So my suggestion would be to use the printout from the ADF test and say
"using 0 lags of (1-L)...".
thanks,
sven
15 years
linespoints translation
by Sven Schreiber
Hi,
in gretl 1.9.0 I just noticed that in the plot control dialog the
gnuplot term (?) linespoints is now translated. Maybe I even did it
myself, but anyway the issue is whether it really should be marked for
translation? Wasn't the argument that it has to remain English to work
with Gnuplot?
thanks,
sven
15 years
matplotlib
by Talha Yalta
It must be pretty labor intensive to make gretl use matpolotlib
instead of gnuplot right?
http://matplotlib.sourceforge.net/gallery.html
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
gretl joy
by Sven Schreiber
Hi,
thanks for 1.9.0!
I had very productive gretl sessions recently with what was becoming
1.9.0. And BTW, the hidden accessors $s00 etc. are very useful for me...
cheers,
sven
15 years, 1 month
Portuguese website update
by Henrique Andrade
Dear Allin,
I'd just updated the Gretl Portuguese website (based upon "index_pat.html"
1.85). Is it possible to publish this update before the next Gretl update?
Best,
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
15 years, 1 month
