Hello all panel-interested people,
while using gretl for teaching with panel data (which I hadn't done much
before) I noticed the following, let's say, interface nuisances compared
to the usual luxury gretl offers for time series:
1: The sample and/or range in the main window (bottom) are given as pure
index numbers, even if "panel data marker strings" (cf. user guide p.23)
are defined. At least for the time dimension it would be useful to show
the sample periods in a human-readable form (through the markers). Also,
I noticed that the period numbers shown do not always coincide with the
values of the "time" index variable, if subsampling is in effect. (Seen
in the CEL.gdt dataset after applying the sample restriction year>1970
1b: A slightly more general suggestion, also for non-panel data: The
active sample restriction criterion could be shown next to the resulting
active sample in the main window. (At least for simple restrictions,
maybe not for complex, multiple ones.)
2: Menu Sample -> Set range: Only the group range can be chosen, not the
periods. Actually, given the often arbitrary ordering of groups, this is
really the less useful dimension to choose a contiguous range from. (I
know I can use "set sample based on criterion" for periods, but that's
not the point.)
3: About pshrink(): A version that returns a full panel series (with
repeated values like pmean() etc.) could be useful -- practical example:
in growth regressions one needs the initial value of output-per-worker
as a regressor. Also maybe it should be called "pfirst()" or something
4: Time-constant variables: I'm not sure how to create variables that
only vary along the cross-section, like it is done with the built-in
pmean() etc. functions. Or how to append them (like the user guide p.114
"adding a time series", but along the other panel dimension).
5: Constant in a fixed-effects regression: I don't understand what gretl
reports as the global constant term in a fixed-effects model, and it
doesn't seem to be defined in the guide. It's also confusing that gretl
complains if one wants to discard the constant in the specification
dialog (when fixed effects are selected). (But obviously gretl
estimates the right thing as the comparison with explicit LSDV
regression shows, just the constant is mysterious -- even if it's the
average of the fixed effects it's not clear where the standard errors
6: Lags not showing in model spec dialog when sample is restricted to a
single period: If I restrict the CEL.gdt data with year==1985, I cannot
include any previously created lags (of y for example) in the
regression, because they don't show up in the variable selector. Because
the subsampled dataset is now treated as "undated", there's also no
"lags..." button in the dialog. -- Actually I don't understand why gretl
"temporarily forgets" the panel structure of the dataset when a single
period is active. It would seem less problematic to treat even a T=1
sample as a special case of panel data if the underlying dataset has a
panel structure; especially in conjunction with point 1 above about
showing the selected periods in the sample.
Ok, that was a long post, sorry, but still necessary I think.
I keep running into situations where gretl doesn't recognize the dates
in my csv files. Now instead of asking for more heuristics and
cleverness, I'm wondering whether it would be possible for the user to
specify the format pattern at the time of opening/importing the file.
E.g. let the user specify the string "yyyy~mm" to denote monthly data
with strange separation characters (this is just an example, not my
I don't know whether in the file-open dialogs there is actually a place
to do that, though....
I've noticed that the built-in function reference doesn't mention the
fact that you can use max and min for vectors.
(I actually thought that once there was a discussion about using these
functions also for 2d-matrices --to produce a scalar--, but I can't find
that anymore and in any case it doesn't work.)
Hi to everyone in the list,
I've got three small suggestions which may make sense to add, or at least
1) I don't get the point why the RESET test is not a category of modtest
but stands for itself alone as "reset". I think it is more intuitive to put
it as modtest --reset.
2) Add the "--silent" option to modtest. If one runs a MC simulation the
output of of a battery of model tests can become really massive...
3) The same issue corresponds to the "coint" command where no --silent
option is available.
the attached file is the result from compacting monthly series to
quarterly. When I try to compact further to annual then I don't get any
options (average, summing, etc.). But I do get the options when I try
Is it because gretl is particularly clever (remembering the prior
compacting method)? In which case I would find a corresponding message
in the dialog window useful. Or is it just a bug?
Thanks to all of you who have run the matrix_perf tests. This will
be helpful in setting gretl's (internal, default) parameters for
using the system BLAS versus OpenMP (where available), versus our
own single-threaded matrix multiplication code.
Let me address some of the little "issues" that have come up, then
I'll offer a brief discussion of the results people have posted.
* Artur getting "error in function printvec, line 1": I think your
gretl sources must be not quite up to date. I'm not seeing this
* "nan" getting printed in the Gflops column in some cases. This is
due to division by zero, really meaning that the timer offered by
the OS is not very good. In the latest matrix_perf update (0.4) I've
converted such results to "inf", which is not true (!) but at least
should get the rank-ordering right.
* Some uncertainty over gretl's identification of the BLAS variant
against which gretl is linked. As I mentioned, gretl is relying on
the "ldd" program for this info.
I thought that in Artur's case gretl was misindentifying the BLAS as
the Netlib "reference" version when it must be some optimized
variant; that was because it was showing as 5-7 times as fast as
"vanilla" on some of the experiments. But Artur tells me he's using
Debian/Ubuntu libblas version 1.2.20110419-5, and that's Netlib OK.
I now think that the Debian guys must be building libblas with very
aggressive optimization at the compiler level, probably inducing
vectorization for amd64. So it seems our detection was right, but my
expectation that Netlib BLAS couldn't be so fast relative to vanilla
Then there was Hélio seeing on stderr, "detect blas: confused, found
too many libs!". This was because we have, in the ldd output:
libblas.so.3 => /lib64/libblas.so.3
libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3
libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3
The first of these lines suggested plain Netlib to gretl, while the
others suggested the BLAS was ATLAS. I'm not sure about this, but I
suspect it really is ATLAS, with ATLAS BLAS having been placed at
/lib64/libblas.so.3 via the "alternatives" mechanism that Sven
mentioned. It would be good if that could be confirmed; then we ccan
adjust our detection code accordingly.
I'll just mention some points that seem of interest to me.
* If Hélio's BLAS is really ATLAS (on Fedora 19), it's surprisingly
unimpressive, coming a poor second to gretl's openmp code (or even
third). Maybe it's single-threaded? Or maybe it's not really ATLAS
* Henrique's Mac Mini (plus follow-up on the MacBook Pro): Apple's
VecLib seems to do quite nicely!
* Ignacio's Dell Xeon: Netlib does quite well in some cases but is
clearly single-threaded and is beaten out by OpenMP on larger
For comparison, I've posted results for my two systems (a desktop
named "myrtle" and laptop named "waverley") at
These show openblas operating at up to 50 times the speed of
"vanilla" and up to 10 times the speed of gretl's openmp -- which
explains why I bothered building openblas for the 64-bit Windows
gretl packge. I would recommend installing openblas on Linux,
though you'd want to make sure that if you do so, it's a build that
uses OpenMP rather than "raw" pthreads, otherwise it will not play
nicely with gretl's internal uses of OpenMP.
I updated gretl to latest cvs and obtained an error which did not occur
using a previous version from last week.
The function I have includes string arguments which are stated as
function latextab (matrix M1, string S1, string S2)
As said, I obtain the following message now:
latextab: argument 15 is of the wrong type (is string, should be strings)
Data types not conformable for operation
It may be related to the latest "array" function where an array of
STRINGS can be used as mentioned in Allin's news on "CVS news, part 2".
Does this mean that the function has to be re-written to something like:
function latextab (matrix M1, strings S1, strings S2)