Open a-s-russo opened 1 month ago
We can definitely change the name of the parameter and will think about splitting it. I hope we have a decision at the start of next week.
Thanks for your prompt reply @Immurb as always. Note that this is not impacting us at all. I raise this only in the interests of improving JDemetra+.
Do you have a use case where you would like to have separate exclude backcast and forecast? Both are calculated with the same model.
The only use case I can think of is in importing a series into JD+ in which one wishes to limit revisions at the start of the series. If the series before importation was not previously using backcasts in the generation of extreme values at the beginning of the series, yet this setting is desired at the current end of the series via forecasts, then the user must make a decision to benefit one end of the series over the other.
I don't think separate models would be needed for backcasts vs forecasts (unless the back of the series is very different to the current end), and this use case would be rare.
A potential enhancement of the 'Excludeforecast' parameter is to separate it into excluding forecasts and excluding backcasts individually, so that forecasts can be excluded in the generation of extreme values whilst backcasts are not excluded, or vice versa.
Note further that the name 'Excludeforecast' could be relabelled more appropriately since it currently refers to excluding both forecasts and backcasts. If not implementing the enhancement idea above, then perhaps 'ExcludeFcastBcast' is clearer? This would also align better with the separation of forecasts vs backcasts elsewhere, such as for forecast and backcast horizons: