Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow separation of excluding forecasts vs backcasts in the generation of extreme values #381

Open
a-s-russo opened this issue Aug 1, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@a-s-russo
Copy link

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.

image

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:

image

@Immurb
Copy link
Member

Immurb commented Aug 1, 2024

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.

@a-s-russo
Copy link
Author

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+.

@Immurb Immurb added the enhancement New feature or request label Aug 2, 2024
@ChristianeHofer
Copy link
Contributor

Do you have a use case where you would like to have separate exclude backcast and forecast? Both are calculated with the same model.

@a-s-russo
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants