Am 31.07.2015 um 15:08 schrieb Riccardo (Jack) Lucchetti:
On Fri, 31 Jul 2015, Sven Schreiber wrote:
>
> In my view producing out-of-sample forecasts is one of the central aims
> of applied time-series econometrics. Gretl then says "sorry I don't
> support this (fully) with my built-in objects series and lists, it makes
> me uneasy". Not exactly a first-class treatment, no?
I have to say, you have a point. However, there's a big difference (in
terms of internal work needed, checks etc) between
(a) starting your job with a dataset that extends into the future
because you know from the start that you'll want to do some forecasting
(and this is possible right now), and
(b) starting your job with a certain dataset and then saying "well I
think I could use a couple more obs, let's extend the dataset"
Whereas from the user's point of view it's not too much to ask to go for
(a) instead of (b).
Well yes and no. It would be impossible to write a function package to
do forecasting because of the limitations. So "asking the user to go for
(a)" in this context would seem to imply you cannot use a contributed
package as with other applications, instead the user has to do at least
some of the prep work herself.
I guess it is conceivable in principle that the out-of-sample range
itself becomes an argument of the function call: Suppose gretl had a new
sample-range object type. Then the user/caller could supply the
sample-to-be-added as an argument to the function that does some
out-of-sample forecasting. That way the responsibility of "mucking" with
the dataset remains with the caller, but the function would be capable
of producing out-of-sample results.
cheers,
sven