-
Notifications
You must be signed in to change notification settings - Fork 62
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
[ML] Improvements to forecasting robustness (part 2) #6
Comments
A note on methodology for item 1 above. The issue we run into is that we currently have to make up our minds immediately as to whether a step has occurred or end up polluting the residual model with values before we've decided there was a step: these will typically be way off the typical (until the trend has adjusted to the new level). The brute force approach for dealing with this would be to create models for hypotheses: there was a step change at T(1), T(2), .... In practice, one would very quickly kill off most alternatives, but this still explodes our memory usage. However, I think for certain types of simple hypotheses, which we also expect to be common, we can do much better from a memory perspective than creating multiple models. In particular, the idea would be to track enough state to apply the change, corresponding to a hypothesis, to the decomposition model and only copy the residual distribution model (which is only a small proportion of the model size). Hypotheses for which this is both possible and makes sense are:
We can delay committing to a hypothesis until we are confident it is true and can also reuse all the machinery we have for model selection for this purpose, so this is actually a fairly small change. |
Following on from issue #5. We also need better support from a forecasting perspective for at least some types of time series' change points. In particular, we need to:
The text was updated successfully, but these errors were encountered: