panel data issues
by Sven Schreiber
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
for example.)
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
instead.
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
come from.)
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.
Cheers,
Sven
10 years
Hansen's Panel Threshold Model
by Artur Tarassow
Dear gretl community,
I just uploaded a function package of Hansen's non-dynamic Panel
Threshold model. The code is based on his original GAUSS procedure and
replicates his paper results. If anybody would like to modify/improve
the code, feel free to do so :-)
Best wishes,
Artur
11 years
plotting commands revamped
by Allin Cottrell
I've just about completed a revamp of gretl's plotting
commands, with the hope of achieving greater consistency and
flexibility -- and in particular, of making it possible to
produce a greater variety of plots non-interactively. If
people can help with some testing, that would be great.
In explaining what I've done, I need to distinguish two sorts
of plotting commands. The first category I'll call "pure"
plotting commands: these all have as their sole purpose the
production of a plot of some kind. This category includes
gnuplot, boxplot, scatters, qqplot.
The second category contains commands that produce some
textual or tabular output, but also produce a plot (at least
under some conditions). This includes:
corrgm, xcorrgm, pergm, hurst, rmplot, leverage, fcast
(and possibly a few others, not yet considered in the
revamping).
So here's the first objective: all of the pure plotting
commands should support the --output=whatever option, and
should behave in the following way. If invoked in batch mode
(that is, via script) the default behaviour is to write an
auto-named gnuplot command file (gpttmp01.plt and so on), but
the --output option can be used to send the plot to a window
(with --output=display) or to a named file, the format of
which is governed by the filename suffix as follows;
.eps -> EPS (encapsulated postscript)
.pdf -> PDF
.png -> PNG
.fig -> Xfig
.emf -> EMF (MS Enhanced Metafile)
.svg -> SVG (Scalable Vector Graphics)
.plt -> named gnuplot command file
If a pure plotting command is invoked in interactive mode
(i.e. typing commands in the GUI gretl console, or using
gretlcli interactively), the default is for the plot to be
displayed in a window, but --output can be used to produce a
specified file instead, as above.
And here's the second objective: all other (non-pure) plotting
commands should have an option, --plot=whatever, which acts
much like the --output option above. The behaviour of these
commands should be as follows. If invoked in batch mode, by
default no plot is produced, but a plot (for display or to
file) can be provoked using --plot. In interactive mode the
plot is produced and sent to a window by default, but it can
be diverted to file using --plot, or suppressed via
--plot=none.
I've written "should" above, but I think this is now mostly
working. Here's a sample test script (which illustrates the
fact that the batch-mode options are also available inside
functions):
<hansl>
function void testplot (series y, list X)
string vname = argname(y)
if vname == ""
vname = "y"
else
series @vname = y
endif
gnuplot @vname --time-series --with-lines
gnuplot @vname --time-series --with-lines --output=display
gnuplot @vname --time-series --with-lines --output=ytime.pdf
boxplot @vname
boxplot @vname --output=display
boxplot @vname --output=ybox.pdf
qqplot @vname
qqplot @vname --output=display
qqplot @vname --output=yqq.pdf
scatters @vname ; X
scatters @vname ; X --output=display
scatters @vname ; X --output=scatters.pdf
end function
open data9-7.gdt
list X = 2 3 4 5
testplot(QNC, X)
</hansl>
And here are a couple of examples for some non-pure plotting
commands:
<hansl>
open AWM.gdt
corrgm CAN
corrgm CAN --plot=display
corrgm CAN --plot=corrgm.pdf
pergm CAN
pergm CAN --plot=display
pergm CAN --plot=pergm.pdf
xcorrgm CAN EEN
xcorrgm CAN EEN --plot=display
xcorrgm CAN EEN --plot=xcorrgm.pdf
</hansl>
<hansl>
open djclose.gdt
rmplot djclose
rmplot djclose --plot=display
rmplot djclose --plot=rmplot.pdf
y = ldiff(djclose)
hurst y
hurst y --plot=display
hurst y --plot=hurst.pdf
</hansl>
The help text for the relevant commands still needs to be
updated in many cases.
Allin
11 years
scrap "halt_on_error" switch?
by Allin Cottrell
Hello all,
I'm thinking that I'd like to get rid of option to do
set halt_on_error off
in gretl. But here's an opportunity to object if you are so
moved.
Brief reminder: halt_on error means that if an error is
encountered in running a script, execution of the script
stops. (When using gretlcli with the -b or --batch flag this
means that the program will exit.) This is the default
behavior, but setting "halt_on_error off" will (with something
less than 100% reliability?) cause script execution to
continue in face of errors -- unless gretl is currently
"compiling" a loop or function, in which case it stops
execution regardless of the halt_on error state.
This mechanism predates the "catch" modifier for commands --
and I would say that unlike "catch" it is pretty much useless
if not dangerous. The halt_on_error off-switch was originally
introduced as an aid to debugging gretl itself, but I haven't
found any use for it in that capacity in the last several
years. It's a complication we could do without.
Just to be clear: if I make the proposed change, it means that
in effect "halt_or_error" is always on. But you can still use
"catch" to test a given script command for an error condition
and continue on error if that seems appropriate.
For (minimal) backward compatibility we could make it so that
issuing the command "set halt_on_error off" does not itself
provoke an error, but just prints something like "Warning:
obsolete 'set' argument ignored".
Allin
11 years
UI bug in Gretl CVS
by Logan Kelly
Hello,
I have found some odd behavior with the Gretl CVS UI in Windows 8. First, I am running Windows 8 64 bit OS and Gretl 1.9.12cvs.
Odd behavior 1.
When I open a script file from the OS explorer window (assuming Gretl is already running), Gretl asks if I want a new session. If I answer yes, everything works fine. If I say no, nothing happens. I think it is supposed to load the script into the current session.
Odd behavior 2.
If I load a script from within the editor, i.e. File->Open, the currently open scrip disappears in favor of the newly opened script, i.e. tabs do not engage. I do believe I have set the option to use tabs to true.
I have not seen these reported on the lists serves, so this might be a Windows 8 problem.
Logan
11 years
