[FEAT] Cross-temporal forecasting

[elephaint]

Temporal reconciliation strategy

• Aggregate temporally using aggregate_temporal, which is a minimal wrapper around aggregate, but in the temporal dimension, using a provided temporal spec
• Reconcile using our current reconcilers (except for in_sample reconcilers)

See the two new examples that showcase temporal reconciliation.

Limitations

• Temporal reconcilation (obviously) doesn't support in_sample reconcilers (as there are no insample residuals for the temporal aggregation in the test set, so we'd need an estimate for that - which seems good for future work)
• Limited to temporal aggregations defined by datetime features, which I think is fine.

Open issues

• First example notebook doesn't work yet; main issue to solve is how the temporal unique ids can be matched back to the forecast df Example works!
• Include an easier evaluate function for cross-temporal forecasts, it now requires to run a somewhat complex itertools double for-loop.
• Unit tests for aggregate_temporal
• Unit tests for make_future_dataframe
• Add temporal-only example
• Add temporal-probabilistic example
• ufe.time_features cannot handle non-timestamp ds columns Input should be timestamp or integer
• Add cross-temporal tags creation unit test
• Fix failures on date features that don't naturally convert to dates
• Add more unit tests on weird aggregation combinations

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[elephaint]

Seems like date features that are not year or days and don't generally easily convert to datetimes are still an issue to be solved🤔

This seems solved.

Not quite yet. The aggregated ids are sorted lexicographically, which messes up the assignment of the dates

[elephaint]

Seems like date features that are not year or days and don't generally easily convert to datetimes are still an issue to be solved🤔

This seems solved.

Not quite yet. The aggregated ids are sorted lexicographically, which messes up the assignment of the dates

Fixed by maintaining order throughout the aggregation. Issues remaining:

• Assignment of bottom dates to aggregated levels is still iffy. Maybe a better direction is to exhaustively get the frequencies from the (limited set of) attributes, and then construct a daterange from a starting point and a number of periods, which are both known at each level.
• FIx handling of series of different lengths. Currently the aggregation can handle it but the timestamp assignment fails, it assigns NaNs
• Add unit test on series of different lengths.

[elephaint]

Seems like date features that are not year or days and don't generally easily convert to datetimes are still an issue to be solved🤔
This seems solved.
Not quite yet. The aggregated ids are sorted lexicographically, which messes up the assignment of the dates

Fixed by maintaining order throughout the aggregation. Issues remaining:

• Assignment of bottom dates to aggregated levels is still iffy. Maybe a better direction is to exhaustively get the frequencies from the (limited set of) attributes, and then construct a daterange from a starting point and a number of periods, which are both known at each level.
• FIx handling of series of different lengths. Currently the aggregation can handle it but the timestamp assignment fails, it assigns NaNs
• Add unit test on series of different lengths.

Assignment of bottom dates to aggregated levels by assigning the observed unique timestamps in a linspace where the step is determined by the number of steps in the temporal aggregation. Also not ideal, but best for the moment.

[jmoralez]

I think we should make this immutable, e.g.

from collections.abc import Sequence

...

target_cols: Sequence[str] = ("y",),  # one-tuple

[elephaint]

Does this work when we have multiple targets? (which is the reason it's a list)