10:02 a.m.
Hi,
the following code doesn't work because as per the spec in the system
case the 'varname' argument should pick one of the endogenous variables
(only) to be forecast.
<hansl>
open denmark
smpl 1 50
var 2 LRY LRM IBO
fcast 1986:3 1987:3 LRY LRM # more than one variable
</hansl>
However, given that normally in gretl you can use a list in the same way
as you would use a series (except if it really really has to be a single
variable only), it would seem natural that you could specify more than
one series in this context.
(In the single-equ. case you would instead define a new variable name
for the fitted values; let me add that this semantic overloading of the
argument strikes me as problematic. I would prefer to have systems and
single-equs treated in close analogy. But it's probably too late now.)
Finally, violations of the 'fcast' syntax right now produce quite
generic "data" or "syntax" errors, perhaps they could be made more
informative -- 'wrong number of arguments', 'object doesn't exist', or
something like that.
thanks,
sven
11:30 p.m.
On Wed, 28 Oct 2015, Sven Schreiber wrote:
Hi,
the following code doesn't work because as per the spec in the system case
the 'varname' argument should pick one of the endogenous variables (only) to
be forecast.
<hansl>
open denmark
smpl 1 50
var 2 LRY LRM IBO
fcast 1986:3 1987:3 LRY LRM # more than one variable
</hansl>
However, given that normally in gretl you can use a list in the
same way as you would use a series (except if it really really has
to be a single variable only), it would seem natural that you
could specify more than one series in this context.
As Jack has pointed out, hansl has some of the characteristics of a
natural language, having co-evolved with gretl over the years in a
way that does not always favour consistency.
The "varname" argument to the "fcast" command is a case in point: it
pre-dates the widespread use of accessors following commands. If I
had this to design from scratch I would drop the "varname" argument
altogether, since it's possible to save whatever one might want to
save via the $fcast accessor. In the particular case above the
preferred approach would be:
<hansl>
open denmark
smpl 1 50
var 2 LRY LRM IBO
fcast 1986:3 1987:3 # if you prefer: --silent
# restrict to forecasts of the first two variables
matrix fc = $fcast[,1:2]
</hansl>
(In the single-equ. case you would instead define a new variable
name for the fitted values; let me add that this semantic
overloading of the argument strikes me as problematic. I would
prefer to have systems and single-equs treated in close analogy.
But it's probably too late now.)
We could drop the "varname" argument from the documentation, but
continue to maintain support for it for the sake of backward
compatibility, for some period.
Finally, violations of the 'fcast' syntax right now produce
quite
generic "data" or "syntax" errors, perhaps they could be made more
informative -- 'wrong number of arguments', 'object doesn't
exist', or something like that.
I notice that up till now we have been producing more informative
error messages on stderr. I've now (in git) moved these messages
into the regular gretl error-message space.
Allin
8:11 a.m.
Am 29.10.2015 um 00:30 schrieb Allin Cottrell:
As Jack has pointed out, hansl has some of the characteristics of a
natural language, having co-evolved with gretl over the years in a way
that does not always favour consistency.
Understood.
The "varname" argument to the "fcast" command is a case in point: it
pre-dates the widespread use of accessors following commands. If I had
this to design from scratch I would drop the "varname" argument
altogether, since it's possible to save whatever one might want to save
via the $fcast accessor. In the particular case above the preferred
approach would be:
<hansl>
open denmark
smpl 1 50
var 2 LRY LRM IBO
fcast 1986:3 1987:3 # if you prefer: --silent
# restrict to forecasts of the first two variables
matrix fc = $fcast[,1:2]
</hansl>
ok, fair enough. The question is whether it can be more efficient to
only request some of the forecasts, instead of producing them all and
then picking some. I guess in principle yes it can be like that, but I
would also think that there are very few cases where the difference is
substantial.
> (In the single-equ. case you would instead define a new variable name
> for the fitted values; let me add that this semantic overloading of
> the argument strikes me as problematic. I would prefer to have systems
> and single-equs treated in close analogy. But it's probably too late
> now.)
We could drop the "varname" argument from the documentation, but
continue to maintain support for it for the sake of backward
compatibility, for some period.
No, I actually think that the single-equ. use makes sense; in one
command you directly create a series that you can look at in your
workfile. I think it would be a regression (non-econometric sense) to
remove that. Dropping the varname argument in the system case is ok,
however. (with the maintained support that you mentioned)
> Finally, violations of the 'fcast' syntax right now produce quite
> generic "data" or "syntax" errors, perhaps they could be made
more
> informative -- 'wrong number of arguments', 'object doesn't
exist', or
> something like that.
I notice that up till now we have been producing more informative error
messages on stderr. I've now (in git) moved these messages into the
regular gretl error-message space.
Very good, thanks,
sven
3341
days inactive
3342
days old
2 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber