sktime: [ENH] Extending Reconciler to include methods which use the sample covariance of base forecast errors

@ciaran-g, I would like to use mint_cov and wls_var methods to reconcile existing base forecasts in a hierachical setup. Reconciler currently only allows the methods bu, ols, wls_str, and td_fcst, none of which are based on the sample covariance of the base forecast errors (since these errors are not available to Reconciler).

A solution to this could be to add a second argument to Reconciler’s fit_transform method - for the errors of the base forecasts. Namely, Reconciler().fit_transform(preds, errors). Then the base forecasts could be reconciled using any of the methods that are available to ReconcilerForecaster.

This would give freedom to developers to use any custom base forecasts in their hierachical setups, without having to give up on the best methods such as mint_cov and wls_var. Thanks!

About this issue

Original URL
State: closed
Created a year ago
Comments: 20 (1 by maintainers)

Commits related to this issue

[ENH] Forecaster that forecasts prescribed known or expert forecast values (#4243) This adds a forecaster, `ForecastKnownValues`, that produces forecasts from a set of known or prescribed values pass... — committed to sktime/sktime by fkiraly a year ago

Most upvoted comments

To give my final feedback on this issue: the new forecaster ForecastKnownValues solves my problem, that is, I can use it within ReconcilerForecaster (as described above) to reconcile any given set of base forecasts in a hierachical setup, using any of the reconciliation methods available in ReconcilerForecaster.

The advantage of this approach is that more reconciliation methods are available compared to ‘Reconciler’.

Ajdin2022 on Mar 5, 2023

However as the models are already being trained in 3 different pipelines

I see. One maybe useful comment is (for next time), if you are working in deployment, it is worth keeping composability and interface homogeneity in mind also on the deployment/container layer. Doing too much of model specification manually may cause “proliferating pipeline design” that is very model specific and hard to maintain, engineering-wise; you may like to refactor-simplify to make the deployment architecture more flexible to model choice. Funny side note, I won’t go too much into detail about technical situations at my current job, but if anyone from work reads this, they will also know what I mean 😃

@fkiraly, there are so many levels before reaching this one 😄

Ajdin2022 on Feb 18, 2023

ok, I’ll try to implement ForecastKnownValues then, maybe @ciaran-g also has a good idea.

I have 3 different pipelines/algorithms creating forecasts for A, B, and C

You could use the HierarchyEnsembleForecaster for that, recently added by @VyomkeshVyas. This allows you to use different forecasters for different levels or nodes at a hierarchy.

So, you could implement the separate strategies for A, B, C as three different forecasters, then stick them in HierarchyEnsembleForecaster. That would also allow you later to rearrange them more flexibly, e.g., if you decide to use C for different levels, or add a strategy D.

fkiraly on Feb 17, 2023