-
Notifications
You must be signed in to change notification settings - Fork 904
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
Fix #1049 - add prior_scale and mode arguments to prophet model's add_seasonality #1829
Fix #1049 - add prior_scale and mode arguments to prophet model's add_seasonality #1829
Conversation
…l's add_seasonality
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1829 +/- ##
=======================================
Coverage 93.95% 93.95%
=======================================
Files 125 125
Lines 11773 11782 +9
=======================================
+ Hits 11061 11070 +9
Misses 712 712 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
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.
Hi @id5h,
Thank you for contributing to darts. Your PR solves the issue of the "not passed" prior_scale
and mode
arguments, however it does not fully address the linked issue as condition_name
remain unsupported. Would it be possible to also cover it in this PR?
Hi @madtoinou , I pushed a simple update, where one can add conditional seasonalities as well. |
Hi @madtoinou , It seems like the failed check is due to an issue with codecov and not with the commited code? |
Hi @id5h, Sorry, last week was quite intense. I hope to be able to find some time during the week to review the code and run some tests. I just re-launched the tests, let's hope Codedev does not fail (it has nothing to do with your code). |
Alright. Thanks for the clarification and the prompt reply :) |
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.
Hi @id5h, thanks a lot for this and sorry for the waiting time 🚀
Looks good to me. I would only suggest to actually use condition_name
similar to how Prophet does it.
At fit/predict time we can check that the user supplied the condition in the future_covariates
series.
What do you think?
@@ -318,13 +334,20 @@ def add_seasonality( | |||
fourier_order: int, | |||
prior_scale: Optional[float] = None, | |||
mode: Optional[str] = None, | |||
condition_func: Optional[types.FunctionType] = None, |
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.
I would suggest to use condition_name
instead of a function and check at fit/predict time that the future_covariates
series contains the boolean (binary) component component_name
.
For this to work we also need to avoid adding the conditions as regressors in the following line:
self.model.add_regressor(covariate) |
I did a quick test and it seems to work fine.
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.
Moved in latest commit to use the condition_name
and future_covariates
instead of sending a function
Also, could you add an entry to the unreleased section in CHANGELOG.md? Thanks! |
|
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.
Very nice, thanks @id5h .
Just some minor comments and then we can merge 🚀
raise_if( | ||
future_covariates is None, | ||
f"Condition name '{attributes['condition_name']}' is required by " | ||
f"the custom seasonality '{seasonality_name}', but future_covariates is None. In addition, " | ||
f"the model should be re-trained with future_covariates.", | ||
logger, | ||
) |
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.
can be dropped as it's enforced in the parent class that user must supply future covariates to predict after having fit the model with future covariates
raise_if( | |
future_covariates is None, | |
f"Condition name '{attributes['condition_name']}' is required by " | |
f"the custom seasonality '{seasonality_name}', but future_covariates is None. In addition, " | |
f"the model should be re-trained with future_covariates.", | |
logger, | |
) |
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.
This will be raised in case a user, for whatever reason, fits a model, calls add_seasonality() after fitting and then predict(). Hence the "model should be retrained with future_covariates" message.
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.
The error is now raised according to the logic in _check_seasonality_conditions()
for seasonality_name, attributes in self._add_seasonalities.items(): | ||
condition_name = attributes["condition_name"] |
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.
Can we add a private method _check_seasonality_conditions()
that checks if all the conditions are in the future covariates and that the conditions are binary? The method can then return the condition columns for the downstream logic.
We use this in fit and predict so it helps to have the logic in a common method.
This should loop through all seasonalities first and capture all missing/invalid conditions before raising the error. It's easier for the user to see when he has multiple missing conditions
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.
Makes sense 👍
Done.
|
||
model.fit(ts, future_covariates=future_covariates) | ||
|
||
forecast = model.predict(30, future_covariates=future_covariates) |
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.
also here, predicting 7 days should already be enough
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.
Done
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.
can you add tests that check that missing condition columns in future covariates and non-binary columns raise an error?
an example for this:
with pytest.raises(ValueError):
model.fit(..., future_covariates=invalid_future_covariates)
...
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.
Done
CHANGELOG.md
Outdated
@@ -29,6 +29,7 @@ but cannot always guarantee backwards compatibility. Changes that may **break co | |||
- Fixed a bug when loading the weights of a `TorchForecastingModel` trained with encoders or a Likelihood. [#1744](https://github.com/unit8co/darts/pull/1744) by [Antoine Madrona](https://github.com/madtoinou). | |||
- Fixed a bug when using selected `target_components` with `ShapExplainer. [#1803](https://github.com/unit8co/darts/pull/#1803) by [Dennis Bader](https://github.com/dennisbader). | |||
- Fixed `TimeSeries.__getitem__()` for series with a RangeIndex with start != 0 and freq != 1. [#1868](https://github.com/unit8co/darts/pull/#1868) by [Dennis Bader](https://github.com/dennisbader). | |||
- Fixed an issue with `prophet_model.Prophet.add_seasonality()` to allow proper use of all passed parameters. [#1829](https://github.com/unit8co/darts/pull/#1829) by [Idan Shilon](https://github.com/id5h). |
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.
I would add this to the model improvements section.
"Prophet
now supports conditional seasonalities, and properly handles all parameters passed to Prophet.add_seasonality()
and model creation parameter add_seasonalities
. ..."
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.
Done
Co-authored-by: Dennis Bader <dennis.bader@gmx.ch>
Co-authored-by: Dennis Bader <dennis.bader@gmx.ch>
…ng fit() and predict()
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.
Really nice, thanks @id5h 🚀
Last comment about slightly changing the error message and then we can merge 💯
Great, thanks @dennisbader . I have one suggestion before merging. What do you think about adding this to the current PR? |
Co-authored-by: Dennis Bader <dennis.bader@gmx.ch>
The |
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.
Thanks for the contribution @id5h 🚀 I applied the last suggestion. We're good to merge now 💯
Fixes #1049 .
Summary
When fitting a prophet model, the add_seasonality function will now properly add the prior_scale and mode to the custom seasonality, in accordance with the behaviour described in the docs.
Other Information