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
11 years, 10 months
My review of Hansl-primer
by Hélio Guilherme
Dear Gretl Masters (Allin and Jack ;)),
I did a review of hansl-primer-a4.pdf (learning hansl), and found very few
defects (one or two):
Chapter 7. Control flow, page 27
scalar x = 1
loop foreach f sqrt exp ln
scalar y = $f(1)
print y
endloop
(Unused "scalar x = 1" )
Chapter 10. Series and Lists, page 41
Another option for appending terms to, or dropping terms from, an existing
list is to use += or +=, respectively, as in
xlist += cpi
zlist -= cpi
(you meant -=)
----
That's it.
Thank you for the excellent book.
Best Regards,
Hélio
12 years
Function packages menu placement
by Allin Cottrell
[Note: moved here from gretl-users]
On Mon, 28 Apr 2014, Sven Schreiber wrote:
> Am 28.04.2014 09:40, schrieb Tim Nall:
>> I suppose another option would be a new top-level menu item, directly
>> on the menu bar, labeled "Downloads". That would be even more
>> accessible. But YMMV. Thanks TMN
>
> All this is worth discussing, and therefore shouldn't go into / delay
> the next release IMHO.
> ...
>
>>>> I quite like the idea. In fact, I wouldn't be against introducing the
>>>> above change in the upcoming new release, even if it should be any
>>>> day now. Allin?
>>>
>>> Yes, Tim has a good point here. I'll experiment with this today.
>
> See above, I think we can experiment calmly.
That's no doubt the wise course, but your message arrived just after I
moved the "/Files/Function files" item to "/Tools/Function packages" and
committed the change (along with updating the translations).
I could revert that change, but my feeling is that now the placement of
this menu item has been drawn to our attention it's pretty much a
no-brainer that it should be under Tools. (I'm against a new top-level
menu tree, as in Tim's second suggestion.)
Any further thoughts on this? (I won't push out a release just yet.)
Allin
12 years
New options for kdensity
by Andreï | Андрей Викторович
Dear Jack and Allin (and Sven... and all other contributors!),
I would like to try a modification of the source codes to make a reality of
some of my dreams. However, my noobish skills in C do not allow me to
obtain all the desired fruits. The original wish is to:
— Enhance the kdensity function via adding more kernels (biweight,
triweight, triangular, uniform, tricube, cosine, opt-cosine, logistic,
semicircle—the latter was found in Wolfram Mathematica (and nowhere else),
and made me laugh very hard);
— Add 4th and 6th-order kernels (enhanced convergence; however, negative
outcomes possible);
— Allow users to choose the number of points for interpolation.
The third goal seems the most feasible one. I examined the *dialogs.c* and
(most important) *kernel.c* and found the following lines:
static int kernel_kn (int nobs)
{
if (nobs >= 200) {
return 200;
} else if (nobs >= 100) {
return 100;
} else {
return 50;
}
}
It seems to be the land of promise for those who would like to advance. I
wonder whether it is possible to add an optional argument that would allow
to set the number of points manually. Like, say, --points=1000. That would
be quite useful when calculating the exact quantiles of the smoothed data
(for instance, when estimating the well-known distributions that depend on
nobs or X'X: Dickey—Fuller, Darbin—Watson etc.).
The second goal seems feasible at least for some functions, since Mr.
Hansen kindly provides the formulæ in his lecture notes (2009) and the
calculation method. Please see the following example and reply whether I
defined the extra kernels correctly (and if so, how can I expand the *int
type* for acceptance of multiple possible values):
/* Biweight = 15/16*(1-z^2)^2 if |x|<1 */
static double biw_pdf (double z)
{
if (fabs(z) >= 1) {
return 0.0;
} else {
return 0.9375 * (1.0 - z * z) * (1.0 - z * z);
}
}
/* Tricube = 70/81*(1-|z|^3)^3 if |x|<1 */
#define TCMULT 0.8641975308641975 /* 70 over 81 */
static double tcb_pdf (double z)
{
if (fabs(z) >= 1) {
return 0.0;
} else {
return TCMULT * (1.0 - abs(z) * z * z) * (1.0 - abs(z) * z * z) * (1.0
- abs(z) * z * z)
}
}
I will be very glad to hear from you whether this could be a nice
enhancement for the kdensity function or a complete waste of time. If I
create all the required prerequisited, will you include that functionality?
--
Yours sincerely, | С уважением,
Andreï V. Kostyrka. | Андрей Викторович Костырка.
http://kostyrka.ru, http://kostyrka.ru/blog
12 years
New function for retrieving data from BLS
by Logan Kelly
Hello,
I have written a function in C# that retrieves data from the BLS API. I can integrate this into gretl using a call to a shell command, i.e. $(...). But I would like to develop, and make available to the gretl community, a getBLS function. Could someone give me some pointers for a better integration of the API call and the gretl script? Or can a command line program be include in a function package? Also, is this a function anyone would use? If so, I might also think about a getFRED function too?
Thanks,
Logan
12 years
translators: new release coming up
by Allin Cottrell
We're planning to release gretl 1.9.99 early next week, so if anyone would
like to update their translation this is a good time to do so.
You might wonder, why 1.9.99? Well, we've been on 1.9.N for ages now, and
we reckon the addition of MPI functionality provides a suitable occasion
to go to 1.10. But MPI is not yet in the "official" documentation and it
needs some more testing. The idea is that next week's will be the last
release before 1.10 and an official MPI roll-out.
(Reminder: there's stand-alone documentation for gretl/MPI at
http://users.wfu.edu/cottrell/tmp/gretl-mpi.pdf This is now a second
draft.)
Allin
12 years
Copy as RTF does not work well under OSX
by Shintaro Nakagawa
Dear Allin,
Thank you for your response.
I’ve tried the latest snapshot, titled with gretl 1.9.15cvs Mac OS X(quartz, x86_64) build date 2014-04-14.
I regret to inform you that when I copy a model table as RTF, I cannot paste it on MS Word.
The paste command on the menu bar is inactive. When I push the shortcut key for paste on Word, nothing happens.
The version of my Word is Word for Mac 2011 version 14.4.1(140326).
Best regards,
Shintaro Nakagawa
12 years
Copy as RTF does not work well under OSX
by Shintaro Nakagawa
Hi,
I am using gretl 1.9.15cvs Mac OSX (quartz,x86_64) build date 2014-04-13
under Mac OSX ver. 10.9.2.
I have a trouble in copying model tables as RTF format.
When I copy a model table as RTF and paste it in MS Words, it is pasted not as a table but as a source file, which starts with, for example,
“{¥rtf1¥par
¥qc
Model 1: OLS, using observations 1950:1-2000:4 (T = 204)¥par
Dependent variable: realcons¥par
¥par
{¥trowd ¥trqc ¥trgaph30¥trleft-30¥trrh262¥cellx1900¥cellx3300¥cellx4700¥cellx6100¥cellx7500¥cellx8000”.
When I save the model table as RTF, Gretl creates a fine RTF file.
Thank you in advance and best regards,
Shintaro Nakagawa
12 years, 1 month
Possible ARMA CMLE bug
by GOO Creations
Hi,
I'm not sure if this is a gretl or cephens bug. I've attached my test
data of 1024 samples, in case the problem needs to be reproduced.
Using an ARIMA(17,0,2) model with conditional MLE and the given test
data, gretl gets stuck in an infinite loop. Just before the infinite
loop starts, the following stderr is printed:
/arma: MA estimate(s) out of bounds
cholbeta: test[18] = 0//
//gretl_matrix_QR_rank: rcond = 9,94709e-20//
//dropping redundant variable 18 (e_1)//
/
After further investigation, I discovered that the infinite loop starts
in plugin/arma.c:167 were the following cephens function is called:
/cerr = polrt(b->temp, b->tmp2, qtot, b->roots);//
/
It seems that the while-loop in cephens/polrt.c is executed over and
over again. Inside the loop there is a "goto tryagn;" statement which
makes the function go back before the loop and then execute the
while-loop again. This happens over and over again (stuck in infinity).
This problem is specific to the given test data, AR order 17 and MA
order 2. If I have different data or different orders, the problem
disappears. Does anyone know what's going wrong?
Chris
12 years, 1 month
