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
11 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
13 years, 3 months
Re: [Gretl-devel] [Gretl-users] Runnining individual regressions in a panel
by Sven Schreiber
[also moving to devel]
Am 29.06.2010 21:29, schrieb Allin Cottrell:
>
> On Tue, 29 Jun 2010, Sven Schreiber wrote:
>>
>> Actually as a goal (2.0-ish?) I think it would be nice if sample
>> restrictions worked better with panel data. For example, something like:
>>
>> smpl 1960 1980 --idtime=year
>>
>> would ideally leave the cross-sectional dimension alone and restrict the
>> time dimension as was intended above.
>>
>> Or alternatively/equivalently:
>> setobs unitcount year --panel-vars
>> smpl 1960 1980 --time-dim
>
> This idea looks quite attractive at first, but I'm afraid it gets
> confusing fast. The trouble is that we have two modes of setting
> the sample, which behave somewhat differently and have different
> support behind the scenes: (a) just shifting the end-points; and
> (b) carving a chunk out of the full dataset on some criterion, and
> making the chunk the current dataset for the time being.
>From the user's point of view in the context of panel data in mode (a)
there's two different kinds of end points: cross-sectional and
time-dimensional. That relatively trivial statement is really the heart
of my argument.
I totally understand the issues on the development side and I also
completely accept it if those turn out to be prohobitive. But the
crucial thing is to acknowledge the natural point of view of panel data
users.
>
> In a panel dataset in the form of stacked time-series (which is
> the representation gretl uses) you can sample in mode (a) by
> choosing a contiguous subset of individuals or units, but sampling
> by time period necessarily involves mode (b): we have to carve the
> dataset up; it's a --restrict operation. The syntax you're
> suggesting in effect "dresses up" a --restrict as if it were a
> simple moving of end points. But we can't make this sort of
> sampling behave in that way and I suspect it will end in tears.
As you say, the internal representation of the data is the key driver
here. But the user doesn't care about that, that's my point. From what I
understand, the current situation in gretl is that the two data
dimensions in panel data are not both treated as "first-class citizens".
The question is what amount of effort should gretl make to change this
situation. The answer may well be: zero; I believe you that it could end
in tears...
cheers,
sven
14 years, 2 months
issue with model table (since 1.9.0?)
by Sven Schreiber
Hi,
a model table assignment inside a function doesn't work anymore
(where "anymore" means with recent cvs gretl and it used to work three
months ago -- I just checked on 1.9.0 on Windows and get the same error,
so maybe it was introduced between 1.8.7 and 1.9.0)
What I mean is something like this:
function void check(...)
mymodel <- tsls ...
end function
check()
gives an error "unknown command mymodel <- ..."
Or is this not supposed to work (anymore) in a function, I don't remember?
thanks,
sven
14 years, 2 months
sampling by time with panel data
by Allin Cottrell
Switching this from users to devel.
On Tue, 29 Jun 2010, Allin Cottrell wrote:
> On Tue, 29 Jun 2010, Sven Schreiber wrote:
> > Actually as a goal (2.0-ish?) I think it would be nice if sample
> > restrictions worked better with panel data. For example, something like:
> >
> > smpl 1960 1980 --idtime=year
>
> This idea looks quite attractive at first, but I'm afraid it gets
> confusing fast. The trouble is that we have two modes of setting
> the sample, which behave somewhat differently and have different
> support behind the scenes...
Some more thoughts on this. By "behave differently" above I mean
this:
(A). When you do
smpl <startobs> <endobs>
this always replaces any previous sample setting that was done in
the same way; and it always compounds (and never replaces)
sub-sampling done via --restrict. This may sound a bit awkward but
in fact I'm pretty sure it's the most intuitive behavior.
(B). When you use --restrict with smpl it compounds any
sample limitation that's already in place, unless you also give
the --replace option.
In effect, the two sampling modes are nested. Use of --restrict
carves out a subset of the data, and "smpl <startobs> <endobs>"
operates relative to the current subset.
So to achieve what you're talking about for panel data in such a
way that it's consistent with what happens with non-panel data
(and not confusingly inconsistent!), we'd need to emulate the
non-panel behavior of "smpl <startobs> <endobs>" quite exactly.
I guess this may be doable, but it won't be very easy.
Allin
14 years, 2 months
Re: [Gretl-devel] [Gretl-users] troubles with shared libraries under cygwin
by denis joubert
Ok sorry. switching to gretl-dev for this.
history of the discussion added.
I have no more informations this morning i will looking for libtool issues.
2010/6/17 Riccardo (Jack) Lucchetti <r.lucchetti(a)univpm.it>:
> On Wed, 16 Jun 2010, Allin Cottrell wrote:
>
>>
>> On Thu, 17 Jun 2010, denis joubert wrote:
>>
>>> Oups an error was done in the previous message...
>>
>> Thanks, Denis, but I think this quite specialized discussion may
>> be trying the patience of subscribers to the gretl-users list. I
>> don't want to cut you off -- it would be very good to come up with
>> a workable recipe for building gretl on cygwin -- but I'd suggest
>> either using the gretl-devel mailing list (google: gretl-devel) or
>> switching to personal email with me. (I'm interested and would
>> like to continue discussion.)
>
> Please keep this thread in gretl-devel. I'm interested too.
>
>
> Riccardo (Jack) Lucchetti
> Dipartimento di Economia
> Università Politecnica delle Marche
>
> r.lucchetti(a)univpm.it
> http://www.econ.univpm.it/lucchetti
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-users
>
Hello Allin,
I found some clues of what is going on when linking the shared librairies .
I added a -debug into the libtool command line and get back what it is
doing (log joined).
So i got the libraries he used to try its link :
+ deplibs='/usr/lib/libgmp.dll.a /usr/lib/libiconv.dll.a
/usr/lib/libintl.dll.a /usr/lib/libpcre.dll.a
/usr/lib/libglib-2.0.dll.a -lz /usr/lib/libxml2.dll.a -ldl -lgfortran
/usr/lib/libblas.dll.a /usr/lib/liblapack.dll.a -L/usr/lib -L/usr/lib
'
When i link manualy a module it work only if add libgretl-1.0.a or
libgretl-1.0.so, you can try for example :
$ g++ ./.libs/arbond.o /usr/lib/libgmp.dll.a /usr/lib/libiconv.dll.a
/usr/lib/libintl.dll.a /usr/lib/libpcre.dll.a
/usr/lib/libglib-2.0.dll.a -lz /usr/lib/libxml2.dll.a -ldl -lgfortran
/usr/lib/libblas.dll.a /usr/lib/liblapack.dll.a -L/usr/lib
../lib/libgretl-1.0.so -L/usr/lib -shared -o test.so
And libtool say what the problem is to us :
*** Warning: This system can not link to static lib archive
../lib/libgretl-1.0.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
So he said that the module should be linked with libgretl-1.0 in
shared version !!! But there are the same problem with libgretl-1.0
(undefined symbol)
so i build myself with my hands libgretl-1.0.dll (with the same
arguments sent to libtool):
g++ adf_kpss.o bhhh_max.o bootstrap.o boxplots.o calendar.o compare.o
compat.o csvdata.o dataio.o dataset.o dbread.o dbwrite.o describe.o
discrete.o estimate.o flow_control.o forecast.o geneval.o genfuncs.o
genlex.o genmain.o gensyntax.o gmm.o graphing.o gretl_bfgs.o
gretl_bundle.o gretl_commands.o gretl_errors.o gretl_fft.o
gretl_foreign.o gretl_func.o gretl_intl.o gretl_list.o gretl_matrix.o
gretl_model.o gretl_panel.o gretl_paths.o gretl_prn.o gretl_restrict.o
gretl_scalar.o gretl_string_table.o gretl_untar.o gretl_utils.o
gretl_www.o gretl_xml.o interact.o kalman.o libset.o matrix_extra.o
missing.o modelprint.o monte_carlo.o nls.o nonparam.o objstack.o
options.o plotspec.o plugins.o printout.o printscan.o pvalues.o
qr_estimate.o random.o strutils.o subsample.o system.o texprint.o
transforms.o tsls.o usermat.o var.o varprint.o vartest.o irfboot.o
bdtr.o btdtr.o chbevl.o chdtr.o const.o expx2.o fdtr.o gamma.o gdtr.o
igam.o igami.o incbet.o incbi.o mtherr.o nbdtr.o ndtr.o ndtri.o pdtr.o
polevl.o polrt.o stdtr.o unity.o airy.o hyp2f1.o hyperg.o i0.o i1.o
iv.o j0.o j1.o jn.o jv.o k0.o k1.o kn.o psi.o struve.o yn.o kv.o
chkder.o dpmpar.o enorm.o fdjac2.o lmder.o lmder1.o lmdif.o lmpar.o
qrfac.o qrsolv.o dlog10.o lbfgsb.o -L/usr/lib -llapack -lblas
-lgfortran -lm -ldl -lz -lxml2 -lz -liconv -lm -lglib-2.0 -lintl
-liconv -lgmp -lfftw3 -lm -shared -o libgretl-1.0.dll
Strange it works...
so back to the plugins :
what the hell !!! I got only :
../libtool --mode=link gcc -module -avoid-version -rpath /usr/lib/gretl-gtk2 -o
arbond.la arbond.lo ../lib/libgretl-1.0.la
libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries
ARGH !
There is something tricky with the cygwin version of libtool even with
a right order of libraries he always find there are undefined
symbols...
thanks.
2010/6/16 denis joubert <denis.joubert(a)gmail.com>:
- Masquer le texte des messages précédents -
> 2010/6/16 Allin Cottrell <cottrell(a)wfu.edu>:
>>
>> On Wed, 16 Jun 2010, denis joubert wrote:
>>
>>> I launched the build process with the latest CVS.
>>> unfortunatly, it didn't worked with shared modules.
>>> So i sent you the log again :-)
>>
>> Thanks! We're still hung up on cygwin's inability to create a
>> shared libgretl (that is what is subsequently making it impossible
>> to build the gretl plugins as shared modules).
>>
>> This time, however, the compiler is giving no clue as what
>> undefined symbols are bothering it when trying to link libgretl.
>> (Before, there was a reference to "errno" being a problem, but
>> that is now gone with current CVS, as should be.)
>>
>> This is quite puzzling, since it seems that all the symbols needed
>> by libgretl should be provided by the various shared libraries on
>> the linker line (libm, libz, libxml2, etc.). Indeed, this
>> condition is satisfied when building on OS X, where the compiler
>> also refuses to build a shared library if there are undefined
>> symbols.
>>
>> Somehow we need to get the compiler to tell us what it thinks is
>> missing. I'll see what I can find out about that.
>
> I have some experiences with that I will try to find out about it too
> if I could get some time for.
>
>>
>> Allin Cottrell
>> _______________________________________________
>> Gretl-users mailing list
>> Gretl-users(a)lists.wfu.edu
>> http://lists.wfu.edu/mailman/listinfo/gretl-users
>>
>
14 years, 2 months
GUI enhancements
by Allin Cottrell
You may be interested to hear of some recent enhancments to the
gretl GUI. These are in CVS and the snapshots for Windows and OS
X.
* Re-ordering of series in dataset. Up till now the only way to
change the order of the series in a gretl dataset was to save
the data under a different name (selecting a revised order for
the series via the "store" command or the GUI dialog), then
copy the new gdt file over the old one. Now you can make
changes via the GUI. Select a series and either right-click
and choose "Edit Attributes" (or type "e") to get the Edit
Attributes dialog. This now has an "ID number" spinner which
lets you reposition the variable. (But note that if you have
defined named lists, or saved models, you will not be able to
make a change that disturbs the order of series that are
referenced by such objects.) If you then save the dataset, the
new order is preserved when you reopen it.
* Re-ordering of regressors in the model selection
dialog. Suppose you have a list of regressors in place in the
right-hand pane of the model dialog, and for reasons of
presentation or comparability you want to change their
order. Up till now you would have to remove the regressors
from the list then refill it in the preferred order. Now you
can select one or more series names and right-click to get a
popup menu with Up and Down arrows. Use these to shift terms
as you wish. (But note that since the constant is always
automatically placed first in gretl output, this popup menu is
not available when the constant is selected.)
* Named lists of series. In the main window's Data menu there
are two new items: "Define list" and "Select listed
variables". "Define list" lets you create a named list; if
more than one series is selected when you choose this item the
selected series are shown as the default list-members (but you
have a chance to alter this). "Select listed variables" gives
you a dialog with a pop-down menu containing all
currently-defined lists: if you choose one, the members of
that list are automatically selected in the main window (so
you can then right-click to get summary statistics, a
correlation matrix, or whatever, for the listed variables).
* Main window right-click menu with multiple series selected,
correlation matrix option: this now presents an initial dialog
with the option of imposing a uniform sample for all the
pairwise correlations, in case of missing data. This
corresponds to the --uniform option for the "corr" command.
Allin Cottrell
14 years, 2 months
Re: [Gretl-devel] trouble with lad function in libretl
by denis joubert
Moving to gretl-devel
because i found what is going on :
in .h of libgretl i got this:
MODEL lad(const int*, double***, DATAINFO*)
but in lad.c module :
int lad_driver (MODEL *pmod, double **Z, DATAINFO *pdinfo)
2010/6/17 denis joubert <denis.joubert(a)gmail.com>
> Hello,
> lad function in libgretl(cvs) seems to doesn't work.
> In the gui it works(release 1.9.0) with the same datas.
>
> it output me many :
> (process:6484): GLib-CRITICAL **: g_rand_int_range: assertion `rand !=
> NULL' failed
>
14 years, 3 months
Gretl for Mac: Default path for Calculator
by Henrique Andrade
Dear Developers,
I'd just realized that the Calculator icon (on gretl's toolbar) doesn't work
(by default) in Mac OS X. I suggest that we put the default path for the
Calculator executable (just like we do with Octave and Ox). What do you
think?
The default path (Mac OS X 10.6.3)for the executable is:
Applications/Calculator.app/Contents/MacOS/Calculator
Best regards,
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
14 years, 3 months
Re: [Gretl-devel] Compiling GRETL with multithreaded ATLAS BLAS & LAPACK
by Hamaad Shah
Greetings,
I really appreciate the great work done by the GRETL team. Not only is it a fantastic econometrics tool, the source code is invaluable for someone who would want to make something similar to GRETL: importing & exporting data in various formats, doing complex calculations and then tying them up in a neat GUI, etc.
I have one question though. I tend to use multithreaded ATLAS with almost all my languages: C/C++, Java, Python, Octave and R. I would like to do the same with GRETL. I think there is a way to do this but I couldn't figure it out myself. So if someone could guide me with the options and flags for ./configure, I would be grateful.
My machine: Ubuntu 64-Bit OS, core2duo and 3GB RAM.
Regards,
Hamaad Musharaf Shah,
Director,
Transglobe Shipping Agency (Pakistan & UAE).
> From: gretl-devel-request(a)lists.wfu.edu
> Subject: Gretl-devel Digest, Vol 40, Issue 11
> To: gretl-devel(a)lists.wfu.edu
> Date: Mon, 31 May 2010 12:00:02 -0400
>
> Send Gretl-devel mailing list submissions to
> gretl-devel(a)lists.wfu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
> or, via email, send a message with subject or body 'help' to
> gretl-devel-request(a)lists.wfu.edu
>
> You can reach the person managing the list at
> gretl-devel-owner(a)lists.wfu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gretl-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: series as special case of lists (Sven Schreiber)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 May 2010 18:32:29 +0200
> From: Sven Schreiber <svetosch(a)gmx.net>
> Subject: Re: [Gretl-devel] series as special case of lists
> To: Gretl development <gretl-devel(a)lists.wfu.edu>
> Message-ID: <4C02931D.3000108(a)gmx.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Am 30.05.2010 10:38, schrieb Allin Cottrell:
> >
> > On Mon, 24 May 2010, Allin Cottrell wrote:
> >
> >> On Mon, 24 May 2010, Sven Schreiber wrote:
> >>
> >>> 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.
> >>
> >> For built-in gretl commands a series works as a one-element list;
> >> I agree (I think) that the same should go for user-defined
> >> functions taking a list argument. I'll look into this.
> >
> > That's now implmented in CVS. If a function wants a list as
> > argument and the user supplies a single series, then we
> > automatically construct a temporary list containing that series.
> > The scope of this list is the function in question; it is
> > destroyed on exit.
> >
>
> First of all, thanks! But what about the function package GUI, is that
> adapted, too?
>
> thanks,
> sven
>
>
> ------------------------------
>
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
> End of Gretl-devel Digest, Vol 40, Issue 11
> *******************************************
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969
14 years, 3 months
