Re: [Gretl-devel] more natural/general fcast (in systems)
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