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.
out of curiosity: what is still on the general to-do list for gretl 2.0?
I'm not talking about a wishlist for incremental features which will
always contain some items and will be added in point releases, but the
big picture -- I've heard there's ongoing work about multiprocessing
support, but apart from that I cannot think of anything fundamental that
is really missing, or is there?
Or actually maybe I do have a suggestion for further "modular extension"
interfaces. Namely: make user-defined functions callable by custom
Example: say somebody writes a function to do a new diagnostic test
after a model is estimated. Say the function is called
'modtest_mynewdiagtest' and the corresponding .inp file has been saved
in a standard (to be defined) place. Then I want the following hansl
code to work:
ols y 0 x
The signature of the user-defined function would be:
'function void modtest_mynewdiagtest (bundle *modelbundle)'
So if gretl encounters an unknown command option, it would check whether
a user-supplied corresponding function definition/file exists, and it
would call that function with the argument of the standard bundle that
the previous estimation command created (if I understand correctly the
way it works now; the internal bundle may have to be exposed to hansl
for that, I don't know).
Then the user-supplied function would presumably print out some results,
and/or add new items to the input bundle which could be used afterwards.
That way gretl could be extended without touching the C source, but from
the point of view of users with the same syntax as the built-in options.
(I guess this would be a bit like do-files in Stata, but I'm not sure.)
Thanks, I wasn't planning to write such a long email....
I was trying to understand how GRETL calculates R^2 for fixed-effects
panel-data models as the value it produces is different from Stata and R's
As far as I have been able to understand, the calculation happens in the
function fix_within_stats in the file lib/src/gretl_panel.c as follows
(line 1758-9 in the current CVS head, comment in the original):
/* should we modify R^2 in this way? */
fmod->rsq = 1.0 - (fmod->ess / fmod->tss);
Here fmod->ess is the error-sum-of-squared from the regression on the
demeaned data but fmod->tss has been overwritten earlier in the function
(line 1750) by the TSS from the pooled regression.
I am a newcomer to this list, so apologies if this has already been
discussed, but it is not clear to me whether the above is a useful measure
of goodness of fit, since a high R^2 would be reported even in situations
where the unit dummies explain a lot of the variation in y while the
explicit regressors do not add much.
I would be grateful if someone can point me to some justification in the
literature for this measure. I also think that the way R^2 is calculated
should be discussed in the User's Guide.
Stata's xtreg reports three different measures of "R^2" (see page 10 of
http://www.stata-press.com/manuals/stata12/xt_xtreg.pdf ) none of which
match the one above. R's plm function from the plm library reports an R^2
which equals the "within" R^2 reported by Stata.
Gretl could report the same value simply by not modifying the values in
apart from providing some forecasting results in the accessors $fcast
and $fcerr, gretl also prints some forecast intervals in the output.
However, if I'm not much mistaken these should only be correct under
normally distributed innovations (whereas $fcast and $fcerr should be
appropriate under less restrictive assumptions).
So I'm proposing to print a corresponding warning, or to print normal
forecast intervals only if explicitly requested, for example with 'fcast
--normal' or similar.
With latest official version, check for updates:
You are running gretl 1.9.14.
This seems to be a pre-release; the latest version available at
http://ricardo.ecn.wfu.edu/pub/gretl/ is 1.9.13
Same with CVS (1.9.15)
Used builds in Fedora 64 bit (problems with RPM link)
after updating from 1.9.13 to the latest snapshot on Windows the
following doesn't work anymore:
string pathsep = "\"
which according to the guide should be explicitly valid (p.110 in the A4
sprintf pathsep "\\"
still does work.)
I was reading the recent emails from Arthur and Giuseppe, and it just
occurred to me that it could be very nice and useful if there was a
gretl site at stackexchange. I find their various sites (the LaTeX
site in particular) very useful.
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
I want to edit a function package using the respective gui. But after
pasting the text and saving the function, gretl crashes. I am using
yesterdays cvs on linux.
I attached a file with the shell output.
it could be that I already reported/complained about some of these
earlier, but this is what I have noticed today:
1) Is there no way to add the $unit series to a panel dataset via the menus?
2) Also panel: The Beck-Katz standard errors (PCSE) fail for me with an
example (fixed-effects) model (using the example CLE.gdt data) when I
include time dummies. Now I'm aware that this could be just my ignorance
in the sense that it may not be possible econometrically -- however, ad
hoc I don't really see why, frankly.
3) The "Save as..." option in the menu really seems to do what other
(most?) programs call "save copy as...", namely the current file with
the old name remains active, not the new one with the new name.