feat: allow for mode="backward"
#44
Conversation
|
cc: @mdancho84 Please take a look when you have the time. This should satisfy what we discussed in the issue The logic is not too ugly, hence I would be comfortable to maintain. |
| @@ -115,3 +120,21 @@ def total_length(self: Self) -> timedelta: | |||
| A `timedelta` object representing the time between `train_start` and `forecast_end`. | |||
| """ | |||
| return self.forecast_end - self.train_start | |||
|
|
|||
| def __add__(self: Self, other: Union[timedelta, pd.Timedelta]) -> SplitState: | |||
There was a problem hiding this comment.
Ended up not using this as for the window="rolling" case it would break and be handled anyway, yet I don't mind to keep it
| train_delta = -self.train_delta | ||
| forecast_delta = -self.forecast_delta | ||
| gap_delta = -self.gap_delta | ||
| stride_delta = -self.stride_delta |
There was a problem hiding this comment.
Flip the sign to maintain the same update logic below
|
@baggiponte would you also be so kind to take a look and drop your opinion? 😁 |
|
At a wedding, will review next week. With pleasure, and thanks for asking 😊 |
|
Looks clean to me! 🔥 |
|
Agree. Let me know once it's merged and I'll begin integrating into pytimetk. |
|
Thanks everyone! I am glad for the positive feedback ✨ @mdancho84 I will merge this one (so you can develop using upstream/main branch), however I would like to:
|
Description
Implements the possibility to specify
mode="backward"so that splits are generate from the end to the beginning.Notice that this (implementation) implies that:
forecast_horizonfor backward mode, while it is not necessarily the case in forward modetrain_sizein both mode's and both window's typeFix #41
TODO
Add specific tests for checking forward vs backward swaps