7:27 a.m.
Dear all,
I am playing around with the fcast command. I am wondering why I can't
provide the no. of steps-ahead by the scalar "k" in the example below.
This would be very helpful when writing functions.
See here:
<hansl>
set verbose off
open denmark.gdt -q
series gM = diff(LRM)
smpl full
ols gM 0 gM(-1) -q
# Works
fcast 1985:1 1987:3 1 --rolling
# Does not work
scalar k = 1
fcast 1985:1 1987:3 k --rolling
</hansl>
Best,
Artur
8:46 a.m.
Am 20.01.2017 um 13:27 schrieb Artur Tarassow:
# Works
fcast 1985:1 1987:3 1 --rolling
# Does not work
scalar k = 1
fcast 1985:1 1987:3 k --rolling
[This could also be a case for the users list perhaps.]
I guess that in the command context gretl expects these kind of unquoted
literal strings. So k is interpreted as a literal letter which doesn't
make sense. Have you tried @k instead?
I sort of expect that Allin is going to enable the use of scalar
variables in this context -- although I'm not sure it wouldn't entrench
the confusion between quoted and unquoted string literals.
cheers,
sven
9:25 a.m.
On Fri, 20 Jan 2017, Sven Schreiber wrote:
Am 20.01.2017 um 13:27 schrieb Artur Tarassow:
> # Works
> fcast 1985:1 1987:3 1 --rolling
>
> # Does not work
> scalar k = 1
> fcast 1985:1 1987:3 k --rolling
[This could also be a case for the users list perhaps.]
I guess that in the command context gretl expects these kind of unquoted
literal strings. So k is interpreted as a literal letter which doesn't make
sense. Have you tried @k instead?
I sort of expect that Allin is going to enable the use of scalar variables in
this context -- although I'm not sure it wouldn't entrench the confusion
between quoted and unquoted string literals.
I think this is simpler than you're making it ;-)
In most gretl commands we (by now) accept the name of a scalar
variable (i.e. an identifier, never a string literal) in place of a
straight numerical value in supplying an integer argument (e.g. a lag
order).
The "fcast" command just got overlooked, and still employed an older
mechanism which would accept only a numerical value. That's now fixed
in git. Thanks to Artur for spotting this.
Allin
9:32 a.m.
Am 20.01.2017 um 15:25 schrieb Allin Cottrell:
On Fri, 20 Jan 2017, Sven Schreiber wrote:
> I sort of expect that Allin is going to enable the use of scalar
> variables in this context -- although I'm not sure it wouldn't
> entrench the confusion between quoted and unquoted string literals.
I think this is simpler than you're making it ;-)
Well, my mental resources are limited ....
thanks,
sven
9:40 a.m.
On Fri, 20 Jan 2017, Sven Schreiber wrote:
Am 20.01.2017 um 15:25 schrieb Allin Cottrell:
> On Fri, 20 Jan 2017, Sven Schreiber wrote:
>> I sort of expect that Allin is going to enable the use of scalar
>> variables in this context -- although I'm not sure it wouldn't
>> entrench the confusion between quoted and unquoted string literals.
>
> I think this is simpler than you're making it ;-)
Well, my mental resources are limited ....
This is, to an extent, historical bias. In earlier times, such a fix would
have been much more difficult. At present, it's rather simple: the
difference comes from the new tokenizer our commander-in-chief put
together singlehandledly in 2014.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:07 a.m.
Thank you for this quick fix, Allin, and for your quick response, Sven.
It works fine now!
Let me tell you that got a big fan of the --rolling option in fcast today!
However, I am wondering whether the "rolling window" scheme could be
added to the fcast command as another option. Of course, this would
require another input selecting the "window size" then. Even though this
can easily be programmed using hansl, it may be worth to add this natively.
Best,
Artur
Am 20.01.2017 um 15:25 schrieb Allin Cottrell:
On Fri, 20 Jan 2017, Sven Schreiber wrote:
> Am 20.01.2017 um 13:27 schrieb Artur Tarassow:
>
>> # Works
>> fcast 1985:1 1987:3 1 --rolling
>>
>> # Does not work
>> scalar k = 1
>> fcast 1985:1 1987:3 k --rolling
>
> [This could also be a case for the users list perhaps.]
>
> I guess that in the command context gretl expects these kind of
> unquoted literal strings. So k is interpreted as a literal letter
> which doesn't make sense. Have you tried @k instead?
>
> I sort of expect that Allin is going to enable the use of scalar
> variables in this context -- although I'm not sure it wouldn't
> entrench the confusion between quoted and unquoted string literals.
I think this is simpler than you're making it ;-)
In most gretl commands we (by now) accept the name of a scalar variable
(i.e. an identifier, never a string literal) in place of a straight
numerical value in supplying an integer argument (e.g. a lag order).
The "fcast" command just got overlooked, and still employed an older
mechanism which would accept only a numerical value. That's now fixed in
git. Thanks to Artur for spotting this.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:31 a.m.
Am 20.01.2017 um 16:07 schrieb Artur Tarassow:
However, I am wondering whether the "rolling window" scheme
could be
added to the fcast command as another option. Of course, this would
require another input selecting the "window size" then. Even though this
can easily be programmed using hansl, it may be worth to add this natively.
I seem to remember that we had the terminology discussion before. Even
gretl's own help text for "rolling" says that then "forecasts are
recursive" -- which begs the question why this isn't called
"--recursive" in the first place. Or I think it's often called sequential.
So what Artur calls "rolling window" is called just "rolling" outside
of
gretl I think. And yes of course, it would be nice.
thanks,
sven
1:30 p.m.
Am 20.01.2017 um 16:31 schrieb Sven Schreiber:
Am 20.01.2017 um 16:07 schrieb Artur Tarassow:
> However, I am wondering whether the "rolling window" scheme could be
> added to the fcast command as another option. Of course, this would
> require another input selecting the "window size" then. Even though this
> can easily be programmed using hansl, it may be worth to add this
> natively.
I seem to remember that we had the terminology discussion before. Even
gretl's own help text for "rolling" says that then "forecasts are
recursive" -- which begs the question why this isn't called
"--recursive" in the first place. Or I think it's often called sequential.
So what Artur calls "rolling window" is called just "rolling" outside
of
gretl I think. And yes of course, it would be nice.
thanks,
sven
Of course it may be called "rolling" as the forecasting origin is
rolling over time. But as you said, having a fixed beginning and a
rolling end is typically labeled as (forward) "recursive" I guess.
Exactly, I mean the scheme in which both the sample beginning and sample
end are moving forwards in time at each iteration.
Best,
Artur
2858
days inactive
2858
days old
7 comments
4 participants
participants (4)
-
Allin Cottrell -
Artur Tarassow -
Riccardo (Jack) Lucchetti -
Sven Schreiber