Re: [Gretl-devel] Bug (?) in hi-freq lag counting of midas
On Tue, 11 Jul 2017, Sven Schreiber wrote:
One more thing, which clearly isn't a bug: Say we have x_m3 /
x_m2 / x_m1. I
initially imitated your way of defining a Midas list like this:
list midasx = x_*
And it works nicely (provided the ordering of the variables is correct).
However, two practical things: First, the requirement to get the ordering
right "manually" strikes me as a little lame, if you excuse the expression.
Shouldn't it be easy for gretl to order (descending) according to the
trailing numbers?
The ordering will be right automatically in the common case of getting
such series via "compact". Reordering the terms for the user would
presumably require use of a new function, something like
list Foo = midas_list(x_*)
since a "genr" statement such as
list Foo = x_*
can't have an option flag, and without such an option how do we know
if the user is trying to create a MIDAS list? (And in general, of
course, we don't want to monkey with the order in which a user puts
series into a list.)
Second, if I create lags (e.g. with hflags), then there will exist
new series like x_m3_1 or similar, automatically named by gretl.
Then if I were to rerun the script with the line from above,
referencing x_*, I would suddenly load many more variables into the
redefined midasx list.
My suggestion is to introduce another wildcard character in addition
to '*', say '?', which would just mean a single character.
OK, I like that one, and it's now done in git.
Allin