-
Notifications
You must be signed in to change notification settings - Fork 66
[ML] Correct ageing of windowed seasonal components #88
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] Correct ageing of windowed seasonal components #88
Conversation
@@ -240,6 +240,7 @@ void CSeasonalComponentAdaptiveBucketing::propagateForwardsByTime(double time, b | |||
if (time < 0.0) { | |||
LOG_ERROR(<< "Can't propagate bucketing backwards in time"); | |||
} else if (this->initialized()) { | |||
time *= m_Time->fractionInWindow(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would be cleaner to simply do that on the next line without changing an input parameter
LGTM, only misses the changelog I think. |
Thanks @hendrikmuhs, I updated the change log and made your suggested change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Just to clarify, when you say "regression" in your description you mean regression w.r.t. an unreleased version? |
c72d88b
to
ea81db2
Compare
ea81db2
to
ce6e71b
Compare
That's correct. Whilst evaluating changes related to #87, I noticed we were getting significantly worse forecasts in one of the unit tests. This turned out to be because we identified a weekday/end cyclic partition, which we didn't before. The fact that the results were worse was down to the problem this PR addresses. |
In particular, we were ageing them too fast and their decay rate should be prorated by the fraction of values with which they are updated.
Investigating a forecasting regression associated with changes targeting #87 showed up an issue with the way we age periodically repeating partitions of the data (such as weekday/end splits). In particular, we were ageing them too fast and their decay rate should be prorated by the fraction of values with which they are updated. For subtle reasons, related to interaction between components in the decomposition, this could lead to biased predictions.
This can affect results for metric and count analyses when the data has distinct weekday/end repeating pattern.