-
Notifications
You must be signed in to change notification settings - Fork 880
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
Feat/encoder improvement #1338
Feat/encoder improvement #1338
Conversation
Codecov ReportBase: 93.68% // Head: 93.67% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #1338 +/- ##
==========================================
- Coverage 93.68% 93.67% -0.01%
==========================================
Files 94 94
Lines 9400 9485 +85
==========================================
+ Hits 8806 8885 +79
- Misses 594 600 +6
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
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, thanks for these changes @dennisbader ! Got a few small comments
scenarios described below. With user `covariates`, it simply copies and returns the `covariates` time index. | ||
|
||
It can be used: | ||
A in combination with :class:`LocalForecastingModel`, or in a model agnostic scenario: |
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.
[Nitpicking - no need to do it if annoying] Instead of supporting all these different cases based on conventions (e.g "if calling from a RegressionModel, set the parameters in this way"), you could consider using factory methods (a bit like we have in TimeSeries). E.g. CovariatesIndexGenerator.for_regression_model(lags, lags_past_cov, lags_fut_cov, out_len)
and CovariatesIndexGenerator.for_torch_model(in_len, out_len)
.
future_covariates = future_covariates[ | ||
start : start + offset * self.training_series.freq | ||
] | ||
future_covariates = future_covariates.slice( |
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.
Don't forget that slice()
is inclusive on the right for DatetimeIndex
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 think it is correct, but let me know if I'm missing something.
start
is one step after end of target series, and we end at:
- n - 1 steps ahead of start for DatetimeIndex (as inclusive with slice)
- n steps ahead of start for RangeIndex (as non-inclusive with slice)
darts/tests/models/forecasting/test_local_forecasting_models.py
Outdated
Show resolved
Hide resolved
darts/timeseries.py
Outdated
@@ -2549,10 +2549,6 @@ def append(self, other: "TimeSeries") -> "TimeSeries": | |||
attrs=self._xa.attrs, | |||
) | |||
|
|||
# new_xa = xr.concat(objs=[self._xa, other_xa], dim=str(self._time_dim)) | |||
if not self._has_datetime_index: |
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 was not needed?
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 was related to
- fixed TimeSeries.append() that dropped "time" index for integer indexed series
Also not forget: shift encodings when using one shot. |
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 @dennisbader !
Summary
Additional improvements:
predict()
accepts a different target than used when fitting the modelAdditional fixes:
TODO (in future PR)