Is there any reason why recursive forecasts cannot be included in the ARIMA option for univariate modelling together with their confidence intervals when the model is truly univariate with no exogenous varisbles included in the specification  Clearly post sample data the MA terms would drop out of the forecasts that would effectively only require the AR parameters and any differencing.

Am 24.11.24 um 11:59 schrieb Sven Schreiber: > Am 23.11.2024 um 18:02 schrieb Brian Revell: >> Is there any reason why recursive forecasts cannot be included in the >> ARIMA option for univariate modelling together with their confidence >> intervals when the model is truly univariate with no exogenous >> varisbles included in the specification Clearly post sample data the >> MA terms would drop out of the forecasts that would effectively only >> require the AR parameters and any differencing. >> > I'm wondering whether what you're trying to achieve is the same thing as > what's called "recursive" in gretl. Maybe it is, but the terminology can > be complex and not always universal. Indeed, good point, Sven. > So: If you have a base sample from t=T1 to t=T2, and you estimate your > Arima model on that sample, and then you want to create forecasts for > the out-of-sample range T2+1 through T2+h, for a certain positive > integer h, you can do that, but we wouldn't call it recursive. Example: > > <hansl> > open AWM18.gdt > > h = 3 > smpl +0 -h # leave some obs for the forecasting range, T2 is now 2017:1 > arima 1 1 1; log(YED) > > fcast --dynamic --out-of-sample # prints out h=3 forecast values up to > 2017:4 > > </hansl> > > This is a forward-iterated forecast. Again, maybe this is _not_ what > you're actually trying to do, I just want to make sure there are no > misunderstandings, because sometimes people call this thing recursive. We just discussed this internally, last week. The option --out-of-sample is expected to produce for all out-of-sample observations after T2 forecasts, irrespective of the provided horizon. Actually, it currently remains unclear, whether it should be allowed to provide an integer for steps-ahead (the max. horizon) jointly with the --out-of-sample option. > In contrast, what gretl calls "recursive" --and I hope I'm getting this > right-- entails updating/re-estimating the model coefficients for every > new value, starting from very early in the original base sample. So T2 > is not fixed anymore (and this could become computationally expensive > for non-OLS estimators). Example: > > <hansl> > open AWM18.gdt > > h = 3 > smpl --full > ols ldiff(YED) const ldiff(YED(-1)) > > fcast h --recursive # prints out many forecast values, each h-step > > </hansl> I think this part is buggy from the gretl side. Here is another example for which also the last two observations are missing. <hansl> open AWM18.gdt h = 3 smpl ; 2016:4 ols ldiff(YED) const ldiff(YED(-1)) --quiet # ERROR: No oos forecasts shown # No difference if omitting "--out-of-sample" fcast h --recursive --out-of-sample smpl 2017:1 $tmax series fc = $fcast # Only for the first 2 observations, forecasts are shown # However, one would expect only a single h=3 forecast value at # date 2017:3 print fc -o </hansl> Artur _______________________________________________ Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/

Am 24.11.24 um 11:59 schrieb Sven Schreiber: > > > fcast h --recursive # prints out many forecast values, each h-step >

I think this part is buggy from the gretl side.

Here is another example for which also the last two observations are missing. <hansl> open AWM18.gdt h = 3 smpl ; 2016:4 ols ldiff(YED) const ldiff(YED(-1)) --quiet # ERROR: No oos forecasts shown # No difference if omitting "--out-of-sample" fcast h --recursive --out-of-sample </hansl>

On Sun, 24 Nov 2024, Sven Schreiber wrote: > I'm noticing that the printout here has no values for the final two > observations - to be honest, I don't know why that is so, all the > necessary ingredients should be there. Can anybody explain this, please? The trouble here is that while this is a dynamic model, that's not clear to gretl. Your on-the-fly specification of the lagged dependent variable as the log-difference of something "hides" from gretl the fact that it's the first lag of the dependent variable. If you did this instead <hansl> open AWM18.gdt h = 3 y = ldiff(YED) ols y const y(-1) fcast h --recursive </hansl> you'd get a dynamic forecast that runs to the end of the dataset.