8000 [ENH] Add warning in `EnbpiForecaster` if train residuals are non-stationary · Issue #8216 · sktime/sktime · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
[ENH] Add warning in EnbpiForecaster if train residuals are non-stationary #8216
@marrov

Description

@marrov

Is your feature request related to a problem? Please describe.
In the original EnbPI paper, authors claim their guarantees on a couple of assumptions, one of them being stationarity of the out-of-bag errors of the train series (residuals). Currently, one can easily set-up an approach that looks feasible on paper, but for which the residuals will be stationary. As this computation is happening under the hood and relies on a couple of assumptions and the nature of the bootstrapped series, I think it would be good idea to make a stationarity test after the interval prediction and warn the issue if the underlying EnbPI assumption is not met, i.e., the residuals are non-stationary.

Describe the solution you'd like
In _predict_interval, we can update the call to fortuna to retrieve the OOB residuals for the train set by:

            conformal_intervals, train_residuals = EnbPI(self.aggregation_function).conformal_interval(
                bootstrap_indices=self.indexes,
                bootstrap_train_preds=np.stack(self._preds),
                bootstrap_test_preds=np.stack(preds),
                train_targets=train_targets.values,
                error=1 - cov,
                return_residuals=True,
            )

Then, these residuals should be stored in a private attribute self._train_residuals for which a stationarity test (the estimator could be optionally set via the EnbpiForecaster initialisation with a sensible default) is run before returning the prediction intervals. If the test fails, the user should be warned that the output intervals are not expected to be accurate due to the breaking of the assumptions.

Describe alternatives you've considered
Maybe just inform the users about this in the docs, but I think being explicit is better.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementAdding new functionality

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0