Forecasting with aeon¶

In forecasting, past data is used to make predictions about future values of a time series. This is distinct from learning tasks such classification, regression and clustering, where it may not be future values being predicted.

This notebook gives a tutorial on forecasting. More specific notebooks in aeon on forecasting are:

• Probabilistic Forecasting
• Hierarchical, Global, and Panel Forecasting
• Forecasting with skearn.

aeon provides a common, scikit-learn-like interface to a variety of classical and ML-style forecasting algorithms, together with tools for building pipelines and composite machine learning models, including temporal tuning schemes, or reductions such as walk-forward application of scikit-learn regressors.

Section 1 provides an overview of common forecasting workflows supported by aeon.

Section 2 discusses the families of forecasters available in aeon.

Section 3 discusses advanced composition patterns, including pipeline building, reduction, tuning, ensembling, and autoML.

Section 4 gives an introduction to how to write custom estimators compliant with the aeon interface.

Table of Contents¶

• 1. Basic forecasting workflows
  • 1.1 Data container format
  • 1.2 Basic deployment workflow - batch fitting and forecasting
    • 1.2.1 Basic deployment workflow in a nutshell
    • 1.2.2 Forecasters that require the horizon when fitting
    • 1.2.3 Forecasters that can make use of exogeneous data
    • 1.2.4 Multivariate Forecasters
    • 1.2.5 Prediction intervals and quantile forecasts
    • 1.2.6 Panel forecasts and hierarchical forecasts
  • 1.3 Basic evaluation workflow - evaluating a batch of forecasts against ground truth observations
    • 1.3.1 The basic batch forecast evaluation workflow in a nutshell - function metric interface
    • 1.3.2 The basic batch forecast evaluation workflow in a nutshell - metric class interface)
  • 1.4 Advanced deployment workflow: rolling updates & forecasts
    • 1.4.1 Updating a forecaster with the update method
    • 1.4.2 Moving the "now" state without updating the model
    • 1.4.3 Walk-forward predictions on a batch of data
  • 1.5 Advanced evaluation worfklow: rolling re-sampling and aggregate errors, rolling back-testing
• 2. Forecasters in aeon - searching, tags, common families
  • 2.1 Forecaster lookup - the registry
  • 2.2 Forecaster tags
    • 2.2.1 Capability tags: multivariate, probabilistic, hierarchical
    • 2.2.2 Finding and listing forecasters by tag)
    • 2.2.3 Listing all forecaster tags)
  • 2.3 Common forecaster types
    • 2.3.1 Exponential smoothing, theta forecaster, autoETS from statsmodels
    • 2.3.2 ARIMA and autoARIMA
    • 2.3.3 BATS and TBATS
    • 2.3.4 Facebook prophet
    • 2.3.5 State Space Model (Structural Time Series)
    • 2.3.6 AutoArima from StatsForecast
• 3. Advanced composition patterns - pipelines, reduction, autoML, and more
  • 3.1 Reduction: from forecasting to regression
  • 3.2 Pipelining, detrending and deseasonalization
    • 3.2.1 The basic forecasting pipeline
    • 3.2.2 The Detrender as pipeline component
    • 3.2.3 Complex pipeline composites and parameter inspection
  • 3.3 Parameter tuning
    • 3.3.1 Basic tuning using ForecastingGridSearchCV
    • 3.3.2 Tuning of complex composites
    • 3.3.3 Selecting the metric and retrieving scores
  • 3.4 autoML aka automated model selection, ensembling and hedging
    • 3.4.1 autoML aka automatic model selection, using tuning plus multiplexer
    • 3.4.2 autoML: selecting transformer combinations via OptimalPassthrough
    • 3.4.3 Simple ensembling strategies
    • 3.4.4 Prediction weighted ensembles and hedge ensembles
• 4. Extension guide - implementing your own forecaster
• 5. Summary

Package imports¶

1. Basic forecasting workflows¶

This section explains the basic forecasting workflows, and key interface points for it.

We cover the following four workflows:

• Basic deployment workflow: batch fitting and forecasting;
• Basic evaluation workflow: evaluating a batch of forecasts against ground truth

observations;

• Advanced deployment workflow: fitting and rolling updates/forecasts; and
• Advanced evaluation worfklow: using rolling forecast splits and computing

split-wise and aggregate errors, including common back-testing schemes.

1.1 Data container format¶

All forecasting workflows make common assumptions on the input data format. aeon uses pandas for representing time series for forecasting:

• pd.DataFrame for time series and sequences. Rows represent time indices, columns

represent variables;

• pd.Series can be used for univariate time series;
• numpy arrays (1D and 2D) can also used.

The Series.index and DataFrame.index are used for representing the time series index. aeon supports pandas integer, period and timestamp indices for simple time series.

aeon supports additional data structures for panel and hierarchical time series, see the data structure notebooks for more details.

Example: as the running example in this tutorial, we use a textbook data set, the Box-Jenkins airline data set, which consists of the number of monthly totals of international airline passengers, from 1949 - 1960. Values are in thousands. See "Makridakis, Wheelwright and Hyndman (1998) Forecasting: methods and applications", exercises sections 2 and 3.

1.2 Basic deployment workflow - batch fitting and forecasting¶

The simplest use case is batch fitting and forecasting, i.e., fitting a forecasting model to one batch of past data, then asking for forecasts at time point in the future.

The steps in this workflow are as follows:

1. Preparation of the data
2. Specification of the time points for which forecasts are requested. This uses a numpy.array or the ForecastingHorizon object.
3. Specification and instantiation of the forecaster. This follows a scikit-learn-like syntax; forecaster objects follow the familiar scikit-learn BaseEstimator interface.
4. Fitting the forecaster to the data, using the forecaster's fit method
5. Making a forecast, using the forecaster's predict method

The below first outlines the vanilla variant of the basic deployment workflow, step-by-step.

At the end, one-cell workflows are provided, with common deviations from the pattern (Sections 1.2.1 and following).

Step 1 - Preparation of the data¶

We assume here the data is assumed to be in pd.Series or pd.DataFrame format.

Step 2 - Specifying the forecasting horizon¶

Now we need to specify the forecasting horizon and pass that to our forecasting algorithm.

There are two main ways of doing this:

• Using a numpy.array of integers. This assumes either integer index or periodic index (PeriodIndex) in the time series; the integer indicates the number of time points or periods ahead we want to make a forecast for. E.g., 1 means forecast the next period, 2 the second next period, and so on.
• Using a ForecastingHorizon object. This can be used to define forecast horizons, using any supported index type as an argument. No periodic index is assumed.

Forecasting horizons can be absolute, i.e., referencing specific time points in the future, or relative, i.e., referencing time differences to the present. As a default, the present is that latest time point seen in any y passed to the forecaster.

numpy.array based forecasting horizons are always relative; ForecastingHorizon objects can be both relative and absolute. In particular, absolute forecasting horizons can only be specified using ForecastingHorizon.

Using a numpy forecasting horizon¶

This will ask for monthly predictions for the next three years, since the original series period is 1 month. To predict only the second and fifth month ahead, one would pass a list as follows:

import numpy as np
fh = np.array([2, 5])  # 2nd and 5th step ahead

Using a ForecastingHorizon based forecasting horizon¶

The ForecastingHorizon object considers the input absolute or relative depending on the is_relative flag.

ForecastingHorizon will automatically assume a relative horizon if temporal difference types from pandas are passed; if value types from pandas are passed, it will assume an absolute horizon.

To define an absolute ForecastingHorizon in our example:

A ForecastingHorizon can be converted from relative to absolute and back via the to_relative and to_absolute methods. Both of these conversions require a compatible cutoff to be passed:

Step 3 - Specifying the forecasting algorithm¶

To make forecasts, a forecasting algorithm needs to be specified. All aeon forecasters follow the same interface, so the steps are the same, no matter which forecaster is chosen.

For this example, we choose the naive forecasting method of predicting the last seen value. More complex specifications are possible, using pipeline and reduction construction syntax; this will be covered later in Section 2.

Step 4 - Fitting the forecaster to the seen data¶

Now the forecaster needs to be fitted to the seen data:

Step 5 - Requesting forecasts¶

Finally, we request forecasts for the specified forecasting horizon. This needs to be done after fitting the forecaster:

1.2.1 The basic deployment workflow in a nutshell¶

For convenience, we present the basic deployment workflow in one cell. This uses the same data, but different version of the NiaveForecaster that predicts the latest value observed in the same month (the parameter sp is the seasonal periodicity).

1.2.2 Forecasters that require the horizon already in fit¶

Some forecasters need the forecasting horizon to be provided in fit. Such forecasters will produce informative error messages when it is not passed in fit. All forecaster will remember the horizon when passed in fit for prediction. An example:

1.2.3 Forecasters that can make use of exogeneous data¶

Many forecasters can make use of exogeneous time series, i.e., other time series that are not to be forecast, but are useful for forecasting y. Exogeneous time series are always passed as an X argument, in fit, predict, and other methods (see below). Exogeneous time series should always be passed as pandas.DataFrames. Most forecasters that can deal with exogeneous time series will assume that the time indices of X passed to fit are a super-set of the time indices in y passed to fit; and that the time indices of X passed to predict are a super-set of time indices in fh, although this is not a general interface restriction. Forecasters that do not make use of exogeneous time series still accept the argument (and do not use it internally).

The general workflow for passing exogeneous data is as follows:

NOTE: as in workflows 1.2.1 and 1.2.2, some forecasters that use exogeneous variables may also require the forecasting horizon only in predict. Such forecasters may also be called with steps 4 and 5 being

forecaster.fit(y, X=X)
y_pred = forecaster.predict(fh=fh, X=X)

1.2.4. Multivariate forecasting¶

All forecasters in aeon support multivariate forecasts - some forecasters are "genuine" multivariate, all others "apply by column".

Below is an example of the general multivariate forecasting workflow, using the VAR (vector auto-regression) forecaster on the Longley dataset from aeon.datasets. The workflow is the same as in the univariate forecasters, but the input has more than one variables (columns).

The input to the multivariate forecaster y is a pandas.DataFrame where each column is a variable.

The result of the multivariate forecaster y_pred is a pandas.DataFrame where columns are the predicted values for each variable. The variables in y_pred are the same as in y, the input to the multivariate forecaster.

There are two categories of multivariate forecasters:

• forecasters that are genuinely multivariate, such as VAR. Forecasts for one

endogeneous (y) variable will depend on values of other variables (X).

• forecasters that are univariate, such as ARIMA. Forecasts will be made by

endogeneous (y) variable, and not be affected by other variables (X).

To display complete list of multivariate forecasters, search for forecasters with 'multivariate' or 'both' tag value for the tag 'y_input_type', as follows:

Univariate forecasters have tag value 'univariate', and will fit one model per column. To access the column-wise models, access the forecasters_ parameter, which stores the fitted forecasters in a pandas.DataFrame, fitted forecasters being in the column with the variable for which the forecast is being made:

1.2.5 Probabilistic forecasting: prediction intervals, quantile, variance, and distributional forecasts¶

aeon provides a unified interface to make probabilistic forecasts. The following methods are possibly available for probabilistic forecasts:

• predict_interval produces interval forecasts. Additionally to any predict arguments, an argument coverage (nominal interval coverage) must be provided.
• predict_quantiles produces quantile forecasts. Additionally to any predict arguments, an argument alpha (quantile values) must be provided.
• predict_var produces variance forecasts. This has same arguments as predict.
• predict_proba produces full distributional forecasts. This has same arguments as predict.

Not all forecasters are capable of returning probabilistic forecast, but if a forecasters provides one kind of probabilistic forecast, it is also capable of returning the others. The list of forecasters with such capability can be queried by registry.all_estimators, searching for those where the capability:pred_int tag has valueTrue.

The basic worfklow for probabilistic forecasts is similar to the basic forecasting workflow, with the difference that instead of predict, one of the probabilistic forecasting methods is used:

Now we present the different probabilistic forecasting methods.

predict_interval - interval predictions¶

predict_interval takes an argument coverage, which is a float (or list of floats), the nominal coverage of the prediction interval(s) queried. predict_interval produces symmetric prediction intervals, for example, a coverage of 0.9 returns a "lower" forecast at quantile 0.5 - coverage/2 = 0.05, and an "upper" forecast at quantile 0.5 + coverage/2 = 0.95.

The return y_pred_ints is a pandas.DataFrame with a column multi-index: The first level is variable name from y in fit (or Coverage if no variable names were present), second level coverage fractions for which intervals were computed, in the same order as in input coverage; third level columns lower and upper. Rows are the indices for which forecasts were made (same as in y_pred or fh). Entries are lower/upper (as column name) bound of the nominal coverage predictive interval for the index in the same row.

Pretty-plotting the predictive interval forecasts:

predict_quantiles - quantile forecasts¶

aeon offers predict_quantiles as a unified interface to return quantile values of predictions. Similar to predict_interval.

predict_quantiles has an argument alpha, containing the quantile values being queried. Similar to the case of the predict_interval, alpha can be a float, or a list of floats.

y_pred_quantiles, the output of predict_quantiles, is a pandas.DataFrame with a two-level column multiindex. The first level is variable name from y in fit (or Quantiles if no variable names were present), second level are the quantile values (from alpha) for which quantile predictions were queried. Rows are the indices for which forecasts were made (same as in y_pred or fh). Entries are the quantile predictions for that variable, that quantile value, for the time index in the same row.

Remark: for clarity: quantile and (symmetric) interval forecasts can be translated into each other as follows.

alpha < 0.5: The alpha-quantile prediction is equal to the lower bound of a predictive interval with coverage = (0.5 - alpha) * 2

alpha > 0.5: The alpha-quantile prediction is equal to the upper bound of a predictive interval with coverage = (alpha - 0.5) * 2

predict_var - variance predictions¶

predict_var produces variance predictions:

The format of the output y_pred_var is the same as for predict, except that this is always coerced to a pandas.DataFrame, and entries are not point predictions but variance predictions.

predict_proba - distribution predictions¶

To predict full predictive distributions, predict_proba can be used. As this returns tensorflow Distribution objects, the deep learning dependency set dl of aeon (which includes tensorflow and tensorflow-probability dependencies) must be installed.

Distributions returned by predict_proba are by default marginal at time points, not joint over time points. More precisely, the returned Distribution object is formatted and to be interpreted as follows:

• Batch shape is 1D and same length as fh
• Event shape is 1D, with length equal to number of variables being forecast
• i-th (batch) distribution is forecast for i-th entry of fh
• j-th (event) component is j-th variable, same order as y in fit/update

To return joint forecast distributions, the marginal parameter can be set to False (currently work in progress). In this case, a Distribution with 2D event shape (len(fh), len(y)) is returned.

1.2.6 Panel forecasts and hierarchical forecasts¶

aeon provides a unified interface to make panel and hierarchical forecasts.

All aeon forecasters can be applied to panel and hierarchical data, which needs to be presented in specific input formats. Forecasters that are not genuinely panel or hierarchical forecasters will be applied by instance.

The recommended (not the only) format to pass panel and hierarchical data is a pandas.DataFrame with MultiIndex row. In this MultiIndex, the last level must be in an aeon compatible time index format, the remaining levels are panel or hierarchy nodes.

Example data:

As stated, all forecasters, genuinely hierarchical or not, can be applied, with all workflows described in this section, to produce hierarchical forecasts.

The syntax is exactly the same as for plain time series, except for the hierarchy levels in input and output data:

Similar to multivariate forecasting, forecasters that are not genuinely hierarchical fit by instance. The forecasters fitted by instance can be accessed in the forecasters_ parameter, which is a pandas.DataFrame where forecasters for a given instance are placed in the row with the index of the instance for which they make forecasts:

If the data is both hierarchical and multivariate, and the forecaster cannot genuinely deal with either, the forecasters_ attribute will have both column indices, for variables, and row indices, for instances, with forecasters fitted per instance and variable:

Further details on hierarchical forecasting, including reduction, aggregation, reconciliation, are presented in the "hierarchical forecasting" tutorial.

1.3 Basic evaluation workflow - evaluating a batch of forecasts against ground truth observations¶

It is good practice to evaluate statistical performance of a forecaster before deploying it, and regularly re-evaluate performance if in continuous deployment. The evaluation workflow for the basic batch forecasting task, as solved by the workflow in Section 1.2, consists of comparing batch forecasts with actuals. This is sometimes called (batch-wise) backtesting.

The basic evaluation workflow is as follows:

1. Splitting a representatively chosen historical series into a temporal training and test set. The test set should be temporally in the future of the training set.
2. Obtaining batch forecasts, as in Section 1.2, by fitting a forecaster to the training set, and querying predictions for the test set
3. Specifying a quantitative performance metric to compare the actual test set against predictions
4. Computing the quantitative performance on the test set
5. Testing whether this performance is statistically better than a chosen baseline performance

NOTE: Step 5 (testing) is currently not supported in aeon, but is on the development roadmap. For the time being, it is advised to use custom implementations of appropriate methods (e.g., Diebold-Mariano test; stationary confidence intervals).

NOTE: Note that this evaluation set-up determines how well a given algorithm would have performed on past data. Results are only insofar representative as future performance can be assumed to mirror past performance. This can be argued under certain assumptions (e.g., stationarity), but will in general be false. Monitoring of forecasting performance is hence advised in case an algorithm is applied multiple times.

Example: In the example, we will us the same airline data as in Section 1.2. But, instead of predicting the next 3 years, we hold out the last 3 years of the airline data (below: y_test), and see how the forecaster would have performed three years ago, when asked to forecast the most recent 3 years (below: y_pred), from the years before (below: y_train). "how" is measured by a quantitative performance metric (below: mean_absolute_percentage_error). This is then considered as an indication of how well the forecaster would perform in the coming 3 years (what was done in Section 1.2). This may or may not be a stretch depending on statistical assumptions and data properties (caution: it often is a stretch - past performance is in general not indicative of future performance).

Step 1 - Splitting a historical data set in to a temporal train and test batch¶

Step 2 - Making forecasts for y_test from y_train¶

This is almost verbatim the workflow in Section 1.2, using y_train to predict the indices of y_test.

Steps 3 and 4 - Specifying a forecasting metric, evaluating on the test set¶

The next step is to specify a forecasting metric. These are functions that return a number when input with prediction and actual series. They are different from sklearn metrics in that they can accept series with indices rather than np .ndarray. Forecasting metrics can be invoked using the functions in aeon.benchmarking .forecasting e.g.,mean_absolute_percentage_error or mean_squared_error.

Step 5 - Testing performance against benchmarks¶

In general, forecast performances should be quantitatively tested against benchmark performances.

1.3.1 The basic batch forecast evaluation workflow in a nutshell - function metric interface¶

For convenience, we present the basic batch forecast evaluation workflow in one cell. This cell is using the lean function metric interface.

1.3.2 The basic batch forecast evaluation workflow in a nutshell - metric class interface¶

For convenience, we present the basic batch forecast evaluation workflow in one cell. This cell is using the advanced class specification interface for metrics.

1.4 Advanced deployment workflow: rolling updates & forecasts¶

A common use case requires the forecaster to regularly update with new data and make forecasts on a rolling basis. This is especially useful if the same kind of forecast has to be made at regular time points, e.g., daily or weekly. aeon forecasters support this type of deployment workflow via the update and update_predict methods.

1.4.1 Updating a forecaster with the update method¶

The update method can be called when a forecaster is already fitted, to ingest new data and make updated forecasts - this is referred to as an "update step".

After the update, the forecaster's internal "now" state (the cutoff) is set to the latest time stamp seen in the update batch (assumed to be later than previously seen data).

The general pattern is as follows:

1. Specify a forecasting strategy
2. Specify a relative forecasting horizon
3. Fit the forecaster to an initial batch of data using fit
4. Make forecasts for the relative forecasting horizon, using predict
5. Obtain new data; use update to ingest new data
6. Make forecasts using predict for the updated data
7. Repeat 5 and 6 as often as required

Example: suppose that, in the airline example, we want to make forecasts a year ahead, but every month, starting December 1957. The first few months, forecasts would be made as follows:

... and so on.

A shorthand for running first update and then predict is update_predict_single - for some algorithms, this may be more efficient than the separate calls to update and predict:

1.4.2 Moving the "now" state without updating the model¶

In the rolling deployment mode, may be useful to move the estimator's "now" state (the cutoff) to later, for example if no new data was observed, but time has progressed; or, if computations take too long, and forecasts have to be queried.

The update interface provides an option for this, via the update_params argument of update and other update funtions.

If update_params is set to False, no model update computations are performed; only data is stored, and the internal "now" state (the cutoff) is set to the most recent date.

1.4.3 Walk-forward predictions on a batch of data¶

aeon can also simulate the update/predict deployment mode with a full batch of data.

This is not useful in deployment, as it requires all data to be available in advance; however, it is useful in playback, such as for simulations or model evaluation.

The update/predict playback mode can be called using update_predict and a re-sampling constructor which encodes the precise walk-forward scheme.

NOTE: commented out - this part of the interface is currently undergoing a re-work. Contributions and PR are appreciated.

1.5 Advanced evaluation worfklow: rolling re-sampling and aggregate errors, rolling back-testing¶

To evaluate forecasters with respect to their performance in rolling forecasting, the forecaster needs to be tested in a set-up mimicking rolling forecasting, usually on past data. Note that the batch back-testing as in Section 1.3 would not be an appropriate evaluation set-up for rolling deployment, as that tests only a single forecast batch.

The advanced evaluation workflow can be carried out using the evaluate benchmarking function. evalute takes as arguments:

• a forecaster to be evaluated
• a scikit-learn re-sampling strategy for temporal splitting (cv below), e.g., ExpandingWindowSplitter or SlidingWindowSplitter
• a strategy (string): whether the forecaster should be always be refitted or just fitted once and then updated

Todo: performance metrics, averages, and testing - contributions to aeon and the tutorial are welcome.

2. Forecasters in aeon - searching, tags, common families¶

This section summarizes how to:

• search for forecasters in aeon
• properties of forecasters, corresponding search options and tags
• commonly used types of forecasters in aeon

2.1 Listing all forecasters in aeon¶

Generally, all forecasters available in aeon can be listed with the all_estimators command.

This will list all forecasters in aeon, even those whose soft dependencies are not installed.

The entries of the last column of the resulting dataframe are classes which could be directly used for construction, or simply inspected for the correct import path.

2.2 Forecaster tags¶

All forecasters aeon have so-called tags which describe properties of the estimator, e.g., whether it is multivariate, probabilistic, or not. Use of tags, inspection, and retrieval will be described in this section.

2.2.1 Capability tags: multivariate, probabilistic, hierarchical¶

Every forecaster has tags, which are key-value pairs that can describe capabilities or internal implementation details.

The most important "capability" style tags are the following:

requires-fh-in-fit - a boolean. Whether the forecaster requires the forecasting horizon fh already in fit (True), or whether it can be passed late in predict (False).

y_input_type - a string. Whether the forecaster is univariate ("univariate"), strictly multivariate ("multivariate"), or can deal with any number of variables ("both").

capability:pred_int - a boolean. Whether the forecaster can return probabilistic predictions via predict_interval etc, see Section 1.5.

ignores-exogeneous-X - a boolean. Whether the forecaster makes use of exogeneous variables X (False) or not (True). If the forecaster does not use X, it can still be passed for interface uniformity, and will be ignored.

capability:missing_values - a boolean. Whether the forecaster can deal with missing data in the inputs X or y.

Tags of a forecaster instance can be inspected via the get_tags (lists all tags) and get_tag (gets value for one tag) methods.

Tag values may depend on hyper-parameter choices.

The y_inner_type and X_inner_type indicate whether the forecaster can deal with panel or hierarchical data natively - if an panel or hierarchical mtype occurs here, it does (see data types tutorial).

An explanation for all tags can be obtained using the all_tags utility, see Section 2.2.3.

2.2.2 Finding and listing forecasters by tag¶

To list forecasters with their tags, the all_estimators utility can be used with its return_tags argument.

The resulting data frame can then be used for table queries or sub-setting.

To filter beforehand on certain tags and tag values, the filter_tags argument can be used:

Important note: as said above, tag values can depend on hyper-parameter settings, e.g., a ForecastingPipeline can handle multivariate data only if the forecaster in it can handle multivariate data.

In retrieval as above, the tags for a class are usually set to indicate the most general potential value, e.g., if for some parameter choice the estimator can handle multivariate, it will appear on the list.

2.2.3 Listing all forecaster tags¶

To list all forecaster tags with an explanation of the tag, the all_tags utility can be used:

2.3 Common forecasters in aeon¶

aeon supports a number of commonly used forecasters, many of them interfaced from state-of-art forecasting packages. All forecasters are available under the unified aeon interface.

Some classes that are currently stably supported are:

• ExponentialSmoothing, ThetaForecaster, and autoETS from statsmodels
• ARIMA and AutoARIMA from pmdarima
• AutoARIMA from statsforecast
• BATS and TBATS from tbats
• PolynomialTrend for forecasting polynomial trends
• Prophet which interfaces Facebook prophet

This is not the full list, use all_estimators as demonstrated in Sections 2.1 and 2.2 for that.

For illustration, all estimators below will be presented on the basic forecasting workflow - though they also support the advanced forecasting and evaluation workflows under the unified aeon interface (see Section 1).

For use in the other workflows, simply replace the "forecaster specification block" ("forecaster=") by the forecaster specification block in the examples presented below.

2.3.1 Exponential smoothing, theta forecaster, autoETS from statsmodels¶

aeon interfaces a number of statistical forecasting algorithms from statsmodels: exponential smoothing, theta, and auto-ETS.

For example, to use exponential smoothing with an additive trend component and multiplicative seasonality on the airline data set, we can write the following. Note that since this is monthly data, a good choic for seasonal periodicity (sp) is 12 (= hypothesized periodicity of a year).

The exponential smoothing of state space model can also be automated similar to the ets function in R. This is implemented in the AutoETS forecaster.

2.3.2 ARIMA and autoARIMA¶

aeon interfaces pmdarima for its ARIMA class models. For a classical ARIMA model with set parameters, use the ARIMA forecaster:

AutoARIMA is an automatically tuned ARIMA variant that obtains the optimal pdq parameters automatically:

2.3.3 BATS and TBATS¶

aeon interfaces BATS and TBATS from the tbats package.

2.3.4 Facebook prophet¶

aeon provides an interface to fbprophet by Facebook.

The current interface does not support period indices, only pd.DatetimeIndex. Consider improving this by contributing the aeon.

2.3.5 State Space Model (Structural Time Series)¶

We can also use the UnobservedComponents class from statsmodels to generate predictions using a state space model.

3. Advanced composition patterns - pipelines, reduction, autoML, and more¶

aeon supports a number of advanced composition patterns to create forecasters out of simpler components:

• Reduction - building a forecaster from estimators of "simpler" scientific types, like scikit-learn regressors. A common example is feature/label tabulation by rolling window, aka the "direct reduction strategy".
• Tuning - determining values for hyper-parameters of a forecaster in a data-driven manner. A common example is grid search on temporally rolling re-sampling of train/test splits.
• Pipelining - concatenating transformers with a forecaster to obtain one forecaster. A common example is detrending and deseasonalizing then forecasting, an instance of this is the common "STL forecaster".
• AutoML, also known as automated model selection - using automated tuning strategies to select not only hyper-parameters but entire forecasting strategies. A common example is on-line multiplexer tuning.

For illustration, all estimators below will be presented on the basic forecasting workflow - though they also support the advanced forecasting and evaluation workflows under the unified aeon interface (see Section 1).

For use in the other workflows, simply replace the "forecaster specification block" ("forecaster=") by the forecaster specification block in the examples presented below.

3.1 Reduction: from forecasting to regression¶

aeon provides a meta-estimator that allows the use of any scikit-learn estimator for forecasting.

• modular and compatible with scikit-learn, so that we can easily apply any scikit-learn regressor to solve our forecasting problem,
• parametric and tuneable, allowing us to tune hyper-parameters such as the window length or strategy to generate forecasts
• adaptive, in the sense that it adapts the scikit-learn's estimator interface to that of a forecaster, making sure that we can tune and properly evaluate our model

Example: we will define a tabulation reduction strategy to convert a k-nearest neighbors regressor (sklearn KNeighborsRegressor) into a forecaster. The composite algorithm is an object compliant with the aeon forecaster interface (picture: big robot), and contains the regressor as a parameter accessible component (picture: little robot). In fit, the composite algorithm uses a sliding window strategy to tabulate the data, and fit the regressor to the tabulated data (picture: left half). In predict, the composite algorithm presents the regressor with the last observed window to obtain predictions (picture: right half).

Below, the composite is constructed using the shorthand function make_reduction which produces a aeon estimator of forecaster scitype. It is called with a constructed scikit-learn regressor, regressor, and additional parameter which can be later tuned as hyper-parameters

In the above example we use the "recursive" reduction strategy. Other implemented strategies are:

• "direct",
• "dirrec",
• "multioutput".

Parameters can be inspected using scikit-learn compatible get_params functionality (and set using set_params). This provides tunable and nested access to parameters of the KNeighborsRegressor (as estimator_etc), and the window_length of the reduction strategy. Note that the strategy is not accessible, as underneath the utility function this is mapped on separate algorithm classes. For tuning over algorithms, see the "autoML" section below.

3.2 Pipelining, detrending and deseasonalization¶

A common composition motif is pipelining: for example, first deseasonalizing or detrending the data, then forecasting the detrended/deseasonalized series. When forecasting, one needs to add the trend and seasonal component back to the data.

3.2.1 The basic forecasting pipeline¶

aeon provides a generic pipeline object for this kind of composite modelling, the TransforemdTargetForecaster. It chains an arbitrary number of transformations with a forecaster. The transformations can either be pre-processing transformations or a post-processing transformations. An example of a forecaster with pre-processing transformations can be seen below.

In the above example, the TransformedTargetForecaster is constructed with a list of steps, each a pair of name and estimator, where the last estimator is a forecaster scitype. The pre-processing transformers should be series-to-series transformers which possess both a transform and an inverse_transform method. The resulting estimator is of forecaster scitype and has all interface defining methods. In fit, all transformers apply fit_transforms to the data, then the forecaster's fit; in predict, first the forecaster's predict is applied, then the transformers' inverse_transform in reverse order.

The same pipeline, as above, can also be constructed with the multiplication dunder method *.

This creates a TransformedTargetForecaster as above, with components given default names.

The names in a dunder constructed pipeline are made unique in case, e.g., two deseasonalizers are used.

Example of a multiple seasonality model:

We can also create a pipeline with post-processing transformations, these are transformations after the forecaster, in a dunder pipeline or a TransformedTargetForecaster.

Below is an example of a multiple seasonality model, with integer rounding post-processing of the predictions:

Both pre- and post-processing transformers can be present, in this case the post-processing transformations will be applied after the inverse-transform of the pre-processing ones.

3.2.2 The Detrender as pipeline component¶

For detrending, we can use the Detrender. This is an estimator of series-to-transformer scitype that wraps an arbitrary forecaster. For example, for linear detrending, we can use PolynomialTrendForecaster to fit a linear trend, and then subtract/add it using the Detrender transformer inside TransformedTargetForecaster.

To understand better what happens, we first examine the detrender separately:

Since the Detrender is of scitype series-to-series-transformer, it can be used in the TransformedTargetForecaster for detrending any forecaster:

3.2.3 Complex pipeline composites and parameter inspection¶

aeon follows the scikit-learn philosophy of composability and nested parameter inspection. As long as an estimator has the right scitype, it can be used as part of any composition principle requiring that scitype. Above, we have already seen the example of a forecaster inside a Detrender, which is an estimator of scitype series-to-series-transformer, with one component of forecaster scitype. Similarly, in a TransformedTargetForecaster, we can use the reduction composite from Section 3.1 as the last forecaster element in the pipeline, which inside has an estimator of tabular regressor scitype, the KNeighborsRegressor:

As with scikit-learn models, we can inspect and access parameters of any component via get_params and set_params:

3.3 Parameter tuning¶

aeon provides parameter tuning strategies as compositors of forecaster scitype, similar to scikit-learn's GridSearchCV.

3.3.1 Basic tuning using ForecastingGridSearchCV¶

The compositor ForecastingGridSearchCV (and other tuners) are constructed with a forecaster to tune, a cross-validation constructor, a scikit-learn parameter grid, and parameters specific to the tuning strategy. Cross-validation constructors follow the scikit-learn interface for re-samplers, and can be slotted in exchangeably.

As an example, we show tuning of the window length in the reduction compositor from Section 3.1, using temporal sliding window tuning:

As with other composites, the resulting forecaster provides the unified interface of aeon forecasters - window splitting, tuning, etc requires no manual effort and is done behind the unified interface:

Tuned parameters can be accessed in the best_params_ attribute:

An instance of the best forecaster, with hyper-parameters set, can be retrieved by accessing the best_forecaster_ attribute:

3.3.2 Tuning of complex composites¶

As in scikit-learn, parameters of nested components can be tuned by accessing their get_params key - by default this is [estimatorname]__[parametername] if [estimatorname] is the name of the component, and [parametername] the name of a parameter within the estimator [estimatorname].

For example, below we tune the KNeighborsRegressor component's n_neighbors, in addition to tuning window_length. The tuneable parameters can easily be queried using forecaster.get_params().

An alternative to the above is tuning the regressor separately, using scikit-learn's GridSearchCV and a separate parameter grid. As this does not use the "overall" performance metric to tune the inner regressor, performance of the composite forecaster may vary.

NOTE: a smart implementation of this would use caching to save partial results from the inner tuning and reduce runtime substantially - currently aeon does not support this. Consider helping to improve aeon.

3.3.3 Selecting the metric and retrieving scores¶

All tuning algorithms in aeon allow the user to set a score; for forecasting the default is mean absolute percentage error. The score can be set using the score argument, to any scorer function or class, as in Section 1.3.

Re-sampling tuners retain performances on individual forecast re-sample folds, which can be retrieved from the cv_results_ argument after the forecaster has been fit via a call to fit.

In the above example, using the mean squared error instead of the mean absolute percentage error for tuning would be done by defining the forecaster as follows:

The performances on individual folds can be accessed as follows, after fitting:

3.4 autoML aka automated model selection, ensembling and hedging¶

aeon provides a number of compositors for ensembling and automated model selection. In contrast to tuning, which uses data-driven strategies to find optimal hyper-parameters for a fixed forecaster, the strategies in this section combine or select on the level of estimators, using a collection of forecasters to combine or select from.

The strategies discussed in this section are:

• autoML aka automated model selection
• simple ensembling
• prediction weighted ensembles with weight updates, and hedging strategies

3.4.1 autoML aka automatic model selection, using tuning plus multiplexer¶

The most flexible way to perform model selection over forecasters is by using the MultiplexForecaster, which exposes the choice of a forecaster from a list as a hyper-parameter that is tunable by generic hyper-parameter tuning strategies such as in Section 3.3.

In isolation, MultiplexForecaster is constructed with a named list forecasters, of forecasters. It has a single hyper-parameter, selected_forecaster, which can be set to the name of any forecaster in forecasters, and behaves exactly like the forecaster keyed in forecasters by selected_forecaster.