5:48 p.m.
Hi,
I think a midasreg with a 'mdsl' term may get the included lags wrong in
the information that is printed in the output.
For example, as a benchmark I have the following (shortened) line:
midasreg dep ... ; ... mds(dO, 2,3 , 2, theta)
So my high-frequency lags of dO go from 2 to 3, and indeed gretl tells
me just that in the output:
MIDAS list dO, high-frequency lags 2 to 3
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
Fine -- I know there are numerical problems here but that's not the
issue right now. I can get the same result by defining a lag list dOL
with hi-freq lags 2 to 3, and then using mdsl:
midasreg dep...; ... mdsl(dOL, 2, theta)
This produces the same result numerically which makes me confident that
I defined the dOL list correctly; however, gretl no tells me the lags
would be from 1 to 2 instead:
MIDAS list dOL, high-frequency lags 1 to 2
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
So this looks like a off-by-one bug to me. (Latest snapshot BTW.)
Thanks,
sven
7:27 p.m.
On Sun, 9 Jul 2017, Sven Schreiber wrote:
I think a midasreg with a 'mdsl' term may get the included
lags wrong in
the information that is printed in the output.
For example, as a benchmark I have the following (shortened) line:
midasreg dep ... ; ... mds(dO, 2,3 , 2, theta)
So my high-frequency lags of dO go from 2 to 3, and indeed gretl tells
me just that in the output:
MIDAS list dO, high-frequency lags 2 to 3
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
Fine -- I know there are numerical problems here but that's not the
issue right now. I can get the same result by defining a lag list dOL
with hi-freq lags 2 to 3, and then using mdsl:
midasreg dep...; ... mdsl(dOL, 2, theta)
This produces the same result numerically which makes me confident that
I defined the dOL list correctly; however, gretl no tells me the lags
would be from 1 to 2 instead:
MIDAS list dOL, high-frequency lags 1 to 2
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
So this looks like a off-by-one bug to me. (Latest snapshot BTW.)
Thanks for beating on midasreg. This is a bug, for sure (though, as
you say, just a bug in the printout). But unfortunately it's not
just a simple off-by-one: in the mdsl() case it's not easy to
reconstruct a correct account of which lags are included. Anyway,
I'll take another look at it.
Allin
2:29 a.m.
Am 10.07.2017 um 01:27 schrieb Allin Cottrell:
On Sun, 9 Jul 2017, Sven Schreiber wrote:
> So this looks like a off-by-one bug to me. (Latest snapshot
BTW.)
Thanks for beating on midasreg. This is a bug, for sure (though, as you
say, just a bug in the printout). But unfortunately it's not just a
simple off-by-one:
Too bad. Anyway, here's another thing: In the GUI for a Midas
regression, if I click on the Lags... button, I'm presented with "const"
instead of the dependent variable. I guess the dep var is already
treated with the extra "AR order" setting in the window. (There are no
other low-freq regressors yet.)
thanks,
sven
2:32 a.m.
Am 10.07.2017 um 08:29 schrieb Sven Schreiber:
Am 10.07.2017 um 01:27 schrieb Allin Cottrell:
Too bad. Anyway, here's another thing: In the GUI for a Midas
regression, if I click on the Lags... button, I'm presented with "const"
instead of the dependent variable. I guess the dep var is already
treated with the extra "AR order" setting in the window. (There are no
other low-freq regressors yet.)
P.S.: And subsequently after "OK" in the Midas reg window gretl crashes
(quits / forced-quit unexpectedly). The visible spec was: the dep var
with AR order 1, a constant term, two midas lists as hi-freq regressors,
with two different coefficient restrictions I think.
thanks,
sven
9:10 a.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 01:27 schrieb Allin Cottrell:
> On Sun, 9 Jul 2017, Sven Schreiber wrote:
>> So this looks like a off-by-one bug to me. (Latest snapshot BTW.)
>
> Thanks for beating on midasreg. This is a bug, for sure (though, as you
> say, just a bug in the printout). But unfortunately it's not just a simple
> off-by-one:
Too bad. Anyway, here's another thing: In the GUI for a Midas
regression, if I click on the Lags... button, I'm presented with
"const" instead of the dependent variable. I guess the dep var is
already treated with the extra "AR order" setting in the window.
(There are no other low-freq regressors yet.)
Hmm, I wonder why the lags button is showing as active. It's supposed
to be active only if there's at least one "plain" regressor besides
the constant.
Experiment: open the supplied gdp_midas.gdt, go to /Model/Time
series/MIDAS, select ld_qgdp as dependent, select ld_payems as
independent. The "lags..." button is greyed out. Can you tell me what
you're doing (or seeing) differently?
(Also: what's the build date of the gretl version?)
Allin
9:15 a.m.
Am 10.07.2017 um 15:10 schrieb Allin Cottrell:
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Experiment: open the supplied gdp_midas.gdt, go to /Model/Time
series/MIDAS, select ld_qgdp as dependent, select ld_payems as
independent. The "lags..." button is greyed out.
Yes it is indeed.
Can you tell me what
you're doing (or seeing) differently?
It becomes active when I choose another regressor, and stays active when
I remove that additional regressor again.
(Also: what's the build date of the gretl version?)
July 6 (and I think on the other machine even a little more recent)
thanks,
sven
9:45 a.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 15:10 schrieb Allin Cottrell:
> On Mon, 10 Jul 2017, Sven Schreiber wrote:
> Experiment: open the supplied gdp_midas.gdt, go to /Model/Time
> series/MIDAS, select ld_qgdp as dependent, select ld_payems as independent.
> The "lags..." button is greyed out.
Yes it is indeed.
Can you tell me what
> you're doing (or seeing) differently?
It becomes active when I choose another regressor, and stays active when I
remove that additional regressor again.
Ah, OK, reproducible here and it's now fixed in git: the lags button
returns to inactive state when only the constant remains in the
Regressors box.
Allin
9:52 a.m.
Am 10.07.2017 um 15:45 schrieb Allin Cottrell:
On Mon, 10 Jul 2017, Sven Schreiber wrote:
> It becomes active when I choose another regressor, and stays
active
> when I remove that additional regressor again.
Ah, OK, reproducible here and it's now fixed in git: the lags button
returns to inactive state when only the constant remains in the
Regressors box.
OK, good. BTW I'm not sure that that's what I had done originally. Could
you perhaps with current git also try what happens when you have two or
three different Midas regressor sets in the equation spec?
thank,
sven
10:58 a.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 15:45 schrieb Allin Cottrell:
> On Mon, 10 Jul 2017, Sven Schreiber wrote:
>> It becomes active when I choose another regressor, and stays active when I
>> remove that additional regressor again.
>
> Ah, OK, reproducible here and it's now fixed in git: the lags button
> returns to inactive state when only the constant remains in the Regressors
> box.
OK, good. BTW I'm not sure that that's what I had done originally. Could you
perhaps with current git also try what happens when you have two or three
different Midas regressor sets in the equation spec?
Checked, and it's OK. The sensitivity of the lags button is controlled
by the content of the Regressors box alone.
Allin
11:09 a.m.
On Sun, 9 Jul 2017, Sven Schreiber wrote:
I think a midasreg with a 'mdsl' term may get the included
lags
wrong in the information that is printed in the output.
For example, as a benchmark I have the following (shortened) line:
midasreg dep ... ; ... mds(dO, 2,3 , 2, theta)
So my high-frequency lags of dO go from 2 to 3, and indeed gretl tells
me just that in the output:
MIDAS list dO, high-frequency lags 2 to 3
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
Fine -- I know there are numerical problems here but that's not the
issue right now. I can get the same result by defining a lag list dOL
with hi-freq lags 2 to 3, and then using mdsl:
midasreg dep...; ... mdsl(dOL, 2, theta)
This produces the same result numerically which makes me confident that
I defined the dOL list correctly; however, gretl no tells me the lags
would be from 1 to 2 instead:
MIDAS list dOL, high-frequency lags 1 to 2
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
I now see what's happening here. We get the lag reporting right in the
mdsl() case if the span of the high frequency lags encompasses at
least one full low-frequency period. In the quarterly/monthly case
that would mean at least 3 monthly lags; with just 2 monthly lags
included our current heuristic fails.
So we need a more robust heuristic. But in the Q/M case it's kinda
strange to include less than 3 lags: that invites numerical problems
since the optimizer doesn't have enough lags to figure out the shape
of the decay function.
Allin
11:23 a.m.
Am 10.07.2017 um 17:09 schrieb Allin Cottrell:
I now see what's happening here. We get the lag reporting right
in the
So we need a more robust heuristic. But in the Q/M case it's
kinda
strange to include less than 3 lags: that invites numerical problems
since the optimizer doesn't have enough lags to figure out the shape of
the decay function.
OK, granted. However I think there are special cases (of Almon?) where
you can reduce the whole thing to a single parameter? So it's not always
absurd to have only two or even one lag. And in any case I guess we
agree that a pre-emptive error message then would be preferable.
And since we're at the Midas stuff, two more remarks:
a) I have a quarterly workfile with some (monthly) Midas lists in there,
and in particular the following series (with ID numbers):
4 ld_orders_m3
5 ld_orders_m2
6 ld_orders_m1
7 BIPnom
When I click on one of 4/5/6, everything 4-7 gets selected, where I
expect only 4-6. I am, however, able to click on ID7 and get only ID7
selected. (With 4-7 selected I can also ctrl-click on ID7 to unselect that.)
b) When I right-click on a Midas group/list and click on "time series
plot" I get one plot. It took me a while to realize that it's a hi-freq
(monthly) plot. Perhaps the x-axis could be automatically labeled with
"months" (=the hi-freq unit) or something like that.
thanks,
sven
2:34 p.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 17:09 schrieb Allin Cottrell:
> I now see what's happening here. We get the lag reporting right in the
> So we need a more robust heuristic. But in the Q/M case it's kinda
> strange to include less than 3 lags: that invites numerical
> problems since the optimizer doesn't have enough lags to figure out
> the shape of the decay function.
OK, granted. However I think there are special cases (of Almon?)
where you can reduce the whole thing to a single parameter? So it's
not always absurd to have only two or even one lag.
Number of parameters has nothing to do with number of lags (unless
you're doing "unrestricted MIDAS"). The point is that you have a
parsimonious parameterization, generally just one or two
hyperparameters, and as many lags as you like. Extra lags don't eat up
degrees of freedom, there's no reason of parsimony to limit the number
tightly, and you want a reasonable number of them to identify the
hyperparameter(s).
Anyway, there's now a fix in git and snapshots for the mis-reporting
of the min and max midas lags when the number of lags is very small.
The fix depends on recording one more piece of metadata concerning
midas series, and to get this working it's probably necessary to
regenerate derivative series such as log differences and lags. The
supplied gdp_midas dataset is now updated to the new spec, and the
following reports the lags correctly:
<hansl>
open gdp_midas.gdt -q
list dX = ld_payems*
list dXL1 = hflags(1, 2, dX)
list dXL2 = hflags(2, 3, dX)
matrix theta = {1,5}
smpl 1985:1 2009:1
midasreg ld_qgdp 0 ld_qgdp(-1) ; mdsl(dXL1, 1, theta)
midasreg ld_qgdp 0 ld_qgdp(-1) ; mdsl(dXL2, 1, theta)
midasreg ld_qgdp 0 ld_qgdp(-1) ; mds(dX, 2, 3, 1, theta)
</hansl>
And since we're at the Midas stuff, two more remarks:
a) I have a quarterly workfile with some (monthly) Midas lists in
there, and in particular the following series (with ID numbers):
4 ld_orders_m3
5 ld_orders_m2
6 ld_orders_m1
7 BIPnom
When I click on one of 4/5/6, everything 4-7 gets selected, where I
expect only 4-6. I am, however, able to click on ID7 and get only
ID7 selected. (With 4-7 selected I can also ctrl-click on ID7 to
unselect that.)
OK, I see what you mean: the midas-list status is somehow bleeding
over onto the following series. Should be a fix soon.
b) When I right-click on a Midas group/list and click on "time
series plot" I get one plot. It took me a while to realize that it's
a hi-freq (monthly) plot. Perhaps the x-axis could be automatically
labeled with "months" (=the hi-freq unit) or something like that.
Yes, good idea.
Allin
3:32 p.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
[...] I think there are special cases (of Almon?) where you can
reduce the whole thing to a single parameter? So it's not always
absurd to have only two or even one lag.
I don't mean to drive this into the ground, but on reflection
including only 2 lags with any of the MIDAS hyperparameterizations
is definitely the wrong thing to do. If you want only two lags, use
the unrestricted (U-MIDAS) specification. Otherwise you're in effect
forcing the algorithm to estimate a smooth decay function with only
two data-points, and this cannot go well.
Things are even worse with the regular beta option, which forces the
weight on the last lag to zero: including two lags is in effect
including just one lag. This is explained in
http://gretl.sourceforge.net/midas/midas_gretl.pdf at
http://gretl.sourceforge.net/midas/
Allin
3:41 p.m.
Am 10.07.2017 um 21:32 schrieb Allin Cottrell:
On Mon, 10 Jul 2017, Sven Schreiber wrote:
> [...] I think there are special cases (of Almon?) where you can reduce
> the whole thing to a single parameter? So it's not always absurd to
> have only two or even one lag.
I don't mean to drive this into the ground, but on reflection including
only 2 lags with any of the MIDAS hyperparameterizations is definitely
the wrong thing to do. If you want only two lags, use the unrestricted
(U-MIDAS) specification. Otherwise you're in effect forcing the
algorithm to estimate a smooth decay function with only two data-points,
and this cannot go well.
Yeah, it's all a question of identification, and I'm definitely a friend
of U-Midas. But if only for pedagogical purposes, it's sometimes
interesting to compare the U-Midas results with low-lag
hyperparametrizations, as long as they're theoretically identified.
thanks,
sven
5:50 p.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 21:32 schrieb Allin Cottrell:
> On Mon, 10 Jul 2017, Sven Schreiber wrote:
>
>> [...] I think there are special cases (of Almon?) where you can reduce the
>> whole thing to a single parameter? So it's not always absurd to have only
>> two or even one lag.
>
> I don't mean to drive this into the ground, but on reflection including
> only 2 lags with any of the MIDAS hyperparameterizations is definitely the
> wrong thing to do. If you want only two lags, use the unrestricted
> (U-MIDAS) specification. Otherwise you're in effect forcing the algorithm
> to estimate a smooth decay function with only two data-points, and this
> cannot go well.
Yeah, it's all a question of identification, and I'm definitely a friend of
U-Midas. But if only for pedagogical purposes, it's sometimes interesting to
compare the U-Midas results with low-lag hyperparametrizations, as long as
they're theoretically identified.
Ghysels argues that while U-MIDAS will fit better in-sample (by
construction, if n(lags) > n(hyperparameters)) it generally does
worse at forecasting out of sample. I can confirm that from my
experiments on US quarterly/monthly data. IMO, setting n(lags) =
n(hyperparameters) does not really produce a meaningful comparison
between U-MIDAS and the functional-form approaches; the latter need
to be allowed sufficient lags to do their thing.
Conversely, it _would_ be meaningful to compare low-order U-MIDAS
with beta or exponential Almon with a comparable number of
parameters (not lags).
Allin
5:57 p.m.
On Mon, 10 Jul 2017, Sven Schreiber wrote:
a) I have a quarterly workfile with some (monthly) Midas lists in
there, and
in particular the following series (with ID numbers):
4 ld_orders_m3
5 ld_orders_m2
6 ld_orders_m1
7 BIPnom
When I click on one of 4/5/6, everything 4-7 gets selected, where I expect
only 4-6.
That's now fixed in git and snapshots.
b) When I right-click on a Midas group/list and click on "time
series plot" I get one plot. It took me a while to realize that
it's a hi-freq (monthly) plot. Perhaps the x-axis could be
automatically labeled with "months" (=the hi-freq unit) or
something like that.
That's now addressed in git and snapshots: see what you think of the
update.
Thanks for both of these points (and also the one about lag
selection via the GUI). When I was implementing MIDAS support I
concentrated on scripting and (obviously) didn't test the GUI
sufficiently. We're now better off in the latter department.
Allin
7:50 a.m.
Am 10.07.2017 um 23:57 schrieb Allin Cottrell:
On Mon, 10 Jul 2017, Sven Schreiber wrote:
That's now fixed in git and snapshots.
> b) When I right-click on a Midas group/list and click on "time series
> plot" I get one plot. It took me a while to realize that it's a
> hi-freq (monthly) plot. Perhaps the x-axis could be automatically
> labeled with "months" (=the hi-freq unit) or something like that.
That's now addressed in git and snapshots: see what you think of the
update.
Will test.
Thanks for both of these points (and also the one about lag selection
via the GUI). When I was implementing MIDAS support I concentrated on
scripting and (obviously) didn't test the GUI sufficiently. We're now
better off in the latter department.
Great!
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?
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. Then I could
write "list midasx = x_m?" and it would never pick up x_m3_1 spuriously.
I am aware that '?' is already used in the ternary expression, but '*'
is also used as another operator, so apparently the parser is clever enough.
thanks,
sven
12:22 p.m.
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
12:34 p.m.
Am 11.07.2017 um 18:22 schrieb Allin Cottrell:
On Tue, 11 Jul 2017, Sven Schreiber wrote:
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_*)
Yes, that's what I thought, too.
> 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.
Great -- I'm eager to test, but right now I have a deadline-y thing
first, unfortunately.
thanks,
sven
5:53 a.m.
Am 11.07.2017 um 18:34 schrieb Sven Schreiber:
Am 11.07.2017 um 18:22 schrieb Allin Cottrell:
>> 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.
Great -- I'm eager to test, but right now I have a deadline-y thing
first, unfortunately.
That seems to work fine, thanks! Just to check, this (* and ?) are only
valid in a 'genr' type context, right?
cheers,
sven
9:14 a.m.
On Wed, 12 Jul 2017, Sven Schreiber wrote:
Am 11.07.2017 um 18:34 schrieb Sven Schreiber:
> Am 11.07.2017 um 18:22 schrieb Allin Cottrell:
>>> 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.
>
> Great -- I'm eager to test, but right now I have a deadline-y thing first,
> unfortunately.
That seems to work fine, thanks! Just to check, this (* and ?) are
only valid in a 'genr' type context, right?
In a sense, but creating a list (even an anonymous) is in itself a
genr-type context. So for example the following works OK:
<hansl>
open data4-1
print b*
print be?rms
logs *e*
ols price 0 b*
</hansl>
Allin
5:36 a.m.
Am 11.07.2017 um 13:50 schrieb Sven Schreiber:
Am 10.07.2017 um 23:57 schrieb Allin Cottrell:
>> b) When I right-click on a Midas group/list and click on
"time series
>> plot" I get one plot. It took me a while to realize that it's a
>> hi-freq (monthly) plot. Perhaps the x-axis could be automatically
>> labeled with "months" (=the hi-freq unit) or something like that.
>
> That's now addressed in git and snapshots: see what you think of the
> update.
Will test.
Hm with yesterday's snapshot I get what looks like a plot title at the
top (above the plot area), saying "ld_indpro (monatlich)", where
ld_indpro is the name in this case, and monatlich is monthly in German.
Fine.
However, in the edit dialog window the label appears as y-axis label,
not title plot, and when I change that label text field and click apply
or OK, nothing happens.
The corresponding gnuplot code result of these GUI actions is:
<gnuplot>
set ylabel "grumbl"
...
set nokey
...
set ylabel ''
set title 'ld_indpro (monatlich)'
</gnuplot>
cheers,
sven
10:23 a.m.
Am 12.07.2017 um 11:36 schrieb Sven Schreiber:
However, in the edit dialog window the label appears as y-axis label,
not title plot, and when I change that label text field and click apply
or OK, nothing happens.
This one is still present in the Aug 17th snapshot.
(E.g. load the gdp_midas.gdt data, click on the ld_indpro Midas group of
variables, right-click and choose time series plot, then right-click to
get the plot edit dialog.)
Should I file a bug in the tracker?
thanks,
sven
11:57 a.m.
On Tue, 12 Sep 2017, Sven Schreiber wrote:
Am 12.07.2017 um 11:36 schrieb Sven Schreiber:
> However, in the edit dialog window the label appears as y-axis label, not
> title plot, and when I change that label text field and click apply or OK,
> nothing happens.
This one is still present in the Aug 17th snapshot.
(E.g. load the gdp_midas.gdt data, click on the ld_indpro Midas group of
variables, right-click and choose time series plot, then right-click to get
the plot edit dialog.)
Should I file a bug in the tracker?
I just took a look at that and fixed it in git.
Allin
12:07 p.m.
Am 12.09.2017 um 17:57 schrieb Allin Cottrell:
I just took a look at that and fixed it in git.
That's great, thanks -- but you didn't think that this was it from my
side, did you?
So I'm sorry to bother you further, but here's a bunch of other minor
Midas issues:
<hansl>
open gdp_midas.gdt
list m = indpro_m?
list lagsm = hflags(0,3, m)
midasreg qgdp const ; mds(m, 0, 5, 0) # works OK
# the following gives the error:
# "mds(): the first term must be a MIDAS list"
# although lagsm _is_ a Midas list (at least in a certain sense)
midasreg qgdp const ; mds(lagsm, 0, 5, 0)
# the following gives uninformative generic "syntax error",
# might inform the user that the number or args is wrong:
midasreg qgdp const ; mds(m, 0, 5)
# the following gives generic "data types not conformable" error,
# instead of "first arg is list, should be scalar"
list lagsm = hflags(m, 0,3)
</hansl>
thanks,
sven
12:11 p.m.
Am 12.09.2017 um 18:07 schrieb Sven Schreiber:
So I'm sorry to bother you further, but here's a bunch of
other minor
Midas issues:
# the following gives the error:
# "mds(): the first term must be a MIDAS list"
# although lagsm _is_ a Midas list (at least in a certain sense)
midasreg qgdp const ; mds(lagsm, 0, 5, 0)
OK, I take that back: according to gretl's Midas documentation
(excellent, as always!) 'lagsm' here would not constitute a Midas list.
But another Midas-related question: Why does the hflist() function
restrict the frequency-ratio parameter to be at least 3? Wouldn't
biannual series also be conceivable? Not that I have ever used them...
thanks,
sven
2622
days inactive
2688
days old
25 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber