Forecast Model Selection Graph Details

This section provides some insight into the operation of the forecast model selection graph as it works in the context of the HPFENGINE procedure. This insight can help you understand the behavior of forecast model selection graphs with respect to output data sets and ODS-related output.

Every time series processed by PROC HPFENGINE during one of its runs uses some form of forecast model selection graph to produce its forecast. Previously these were limited to a one-level model selection list. The model selection list held the names of the time series models in its list. In the context of the forecast model selection graph, more complex forecasting scenarios are now possible. Figure 1 depicts the forecast model selection graph equivalent for the one-level model selection list.

Figure 1: Simple Model Selection List

Every forecast model selection graph starts with a single root node which must be a model selection list node. The forecast model selection graph generated from the root model selection list must contain at least one time series forecasting model to use in forecasting the time series realization for which it is used. Forecast model selection graphs that have no time series model specifications can produce no forecast by themselves. Obviously, only the last-chance forecasts in PROC HPFENGINE can handle the failed forecast from any such forecast model selection graph; without any time series models in the forecast model selection graph, there is nothing to produce any forecast for any list to either combine or select. Output 17.13 depicts the forecast model selection graph for a two-level forecasting process.

The root model selection list in the forecast model selection graph defines some properties that apply to all of the nodes in the forecast model selection graph. These properties include:

The stages of PROC HPFENGINE’s execution, its so-called “tasks,” perform as usual in the context of the more general forecast model selection graph with the natural extension from the one-level model selection list. When a TASK=SELECT invocation is used, the best forecast from the forecast model selection graph is selected. Then the best path through the forecast model selection graph is fitted and forecast to produce a final forecast for any time series realization where it is used. When a TASK=FIT, UPDATE, or FORECAST invocation is used, the saved model and parameter information from a previous OUTEST data set is used to restore the context needed to run the best path through the forecast model selection graph as directed by the specified TASK= option.

As noted from the examples, the specification name forms the basis for constructing the forecast model selection graph and connecting it together. Nodes in the forecast model selection graph generally fall into two distinct groups: lists and leaf nodes. Leaf nodes, as the name implies, are terminal in the forecast model selection graph. They represent instances of one of the time series model families: ESM, IDM, ARIMA, UCM, or EXM. List nodes, as the name implies, are lists of specifications, or more correctly, specification names. In general, the specification name that appears in a list can be the name of a leaf node or the name of another list. For obvious reasons, cycles are not permitted in the forecast model selection graph (the forecast model selection graph is a rooted-DAG).

Lists fall into two categories:

Each node in the forecast model selection graph is viewed by any consumer of its results as the source of a time series forecast. Lists define context that is directly applied to the evaluation of time series models that belong to the list. Each list is uniquely identified in the context of the forecast model selection graph construction by its name, and the topology of the forecast model selection graph is determined by the arcs that connect a list to its specifications. The same time series model specifications can belong to different lists in the forecast model selection graph, and they are evaluated independently in the context of their respective lists. The results of a list can be consumed by many traversal paths through the forecast model selection graph, but the list’s results are computed only once when first demanded and then consumed by all traversal paths that reference the list. Apart from the previous discussion of shared root node properties, a list node does not inherit properties accumulated along the traversal path that demands its results. So properties such as the maps are autonomously defined in the scope of each list to satisfy the needs of the time series models that are referenced from the list. Each list is endowed with those properties from its definition via PROC HPFSELECT and subjected overrides from the invocation of PROC HPFENGINE. The isolation of the computation of a list node’s forecast from any traversal path context enables all consumers to share its forecast. Output 17.14 depicts the forecast model selection graph of a forecasting process with multiple nodes that consume the results of a common list node.