On Fri, 31 Jul 2015, Riccardo (Jack) Lucchetti wrote:
On Fri, 31 Jul 2015, Sven Schreiber wrote:
> 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.
Yes, this is true. As long as the "encapsulation principle" is safe (what
happens in the function stays in the function), I'm ok with this.
I agree that this is worth exploring.
If we can come up with a reasonably clear way by which the user can
signal to a function, "It's OK to add observations to my dataset" (the
extra observations to persist after the function exits) that will
clearly enhance the opportunities for package authors who want to
offer forecasting functionality. I'm not sure that the best way to do
this is via a new object type, but that's to be determined.
Allin