Re: [Gretl-devel] The mysterious stack() function
On Wed, 5 Sep 2018, Sven Schreiber wrote:
A colleague made me notice the stack() function for handling a
specific case of panel data import in section 4.5 of the guide. I
must admit I have never been aware of that function, and I have
one or two questions here.
First, it does not appear in the function index (Gretl Command
Reference / Functions proper, or in the built-in function
documentation). Is this an oversight, or is there a deeper reason?
Secondly, it is well documented in the guide section 4.5, but it
appears to be a strange beast: It is not a gretl command (gets
function arguments in parentheses, for example), but there are
double-dash options such as --offset or --length. I don't remember
to have seen something like this in gretl (or hansl) before.
I guess the story here is some path dependence of the early days,
but I wonder if this area could be cleaned up somehow?
Sorry it has taken a while for me to get back about this.
Yes, the stack "function" is an oddball. But it's not quite unique
if you look at it the right way. Most gretl commands (if they take
arguments at all) take simple, unstructured or minimally structured
arguments such as series, or lists, or integer lag orders, or
filenames. But in some cases we have a need for more structured
arguments, and then we have defined special function-like thingies
that are command-specific. Examples include the GMM() apparatus for
the "arbond" and "dpanel" commands, and the mds()/mdsl() apparatus
for the "midasreg" command.
But (I hear you say) "stack()" appears in its own right, not as
ancillary to a command. True, and that's the anomaly. My
interpretation is that stack() is ancillary to a silent, unstated
command which we might call "panelize": a means of transforming a
dataset that has been read from CSV or similar, and that in fact
represents a panel, into something that gretl recognizes as panel
data.
Why isn't stack() documented as a function? Because it's not really
a function as understood in modern hansl. It responds to option
flags, like a command. Moreover, it modifies the dimensions of the
dataset, which by modern hansl convention is forbidden for functions
but acceptable for commands (e.g. the "dataset" command).
So what should we do? We could make the implicit "panelize" command
explicit -- but to avoid breaking old scripts we should presumably
continue to accept stack() as documented at present. However, this
whole apparatus, IIRC, pre-dates easy traffic between series and
matrices, and it seems to me that a modern approach to panelization
of an imported dataset in gretl would probably go via matrices
rather than using stack().
Allin