-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[timeseries] Avoid masking the 'scaler' param with the default 'target_scaler' value #5131
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
Conversation
…aler' in MLForecast models
timeseries/src/autogluon/timeseries/models/autogluon_tabular/mlforecast.py
Outdated
Show resolved
Hide resolved
@@ -191,7 +191,10 @@ def _get_mlforecast_init_args( | |||
self._sum_of_differences = sum(differences) | |||
|
|||
# Support "scaler" for backward compatibility | |||
scaler_type = model_params.get("target_scaler", model_params.get("scaler")) | |||
if "scaler" in model_params: |
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.
What happens if user provides both scaler
and target_scaler
? Should we raise or warn?
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, does this imply any documentation changes?
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.
Before this PR: scaler
is always ignored, only target_scaler
matters.
This PR (at the time of review): scaler
takes precedence over target_scaler
(probably not ideal)
I have updated the PR so that target_scaler
takes precedence over scaler
- that seems more reasonable to me.
We don't need to update the docs - they already only reference the new name target_scaler
.
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've also added a warning to avoid introducing a potentially breaking change in a hotfix release.
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.
@abdulfatir, regarding the warnings category, DeprecationWarning
s are often silenced by the default warning filters (see #3463 or PEP565), so I would prefer to keep the UserWarning
here to ensure that it's displayed.
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.
Looks good to me, but at this stage maybe it's better to just make it a deprecation warning for future clarity. I'll let you decide.
Job PR-5131-dacc27c is done. |
Issue #, if available:
Description of changes:
scaler
hyperparameter to choose the scaling option in MLForecast models. In v1.3.0, we renamed this hyperparameter totarget_scaler
for consistency with other models. We intended to support thescaler
hyperparameter as well for backwards compatibility. However, because of a bug in the logic,scaler
was always shadowed by the default value of thetarget_scaler
, so the old parameter name got effectively deprecated. This can result in unexpected performance changes to the users. This PR fixes this problem.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.