diff --git a/datasetsforecast/index.mdx b/datasetsforecast/index.mdx index f580e31a..67f4b300 100644 --- a/datasetsforecast/index.mdx +++ b/datasetsforecast/index.mdx @@ -10,14 +10,13 @@ pip install datasetsforecast ## Datasets -- [Favorita](https://nixtlaverse.nixtla.io/datasetsforecast/favorita.html) -- [Hierarchical](https://nixtlaverse.nixtla.io/datasetsforecast/hierarchical.html) -- [Long - horizon](https://nixtlaverse.nixtla.io/datasetsforecast/long_horizon.html) -- [M3](https://nixtlaverse.nixtla.io/datasetsforecast/m3.html) -- [M4](https://nixtlaverse.nixtla.io/datasetsforecast/m4.html) -- [M5](https://nixtlaverse.nixtla.io/datasetsforecast/m5.html) -- [PHM2008](https://nixtlaverse.nixtla.io/datasetsforecast/phm2008.html) +- [Favorita](favorita) +- [Hierarchical](hierarchical) +- [Long horizon](long_horizon) +- [M3](m3) +- [M4](m4) +- [M5](m5) +- [PHM2008](phm2008) ## How to use diff --git a/hierarchicalforecast/examples/australiandomestictourism-bootstraped-intervals.html.mdx b/hierarchicalforecast/examples/australiandomestictourism-bootstraped-intervals.html.mdx index c3e0247b..f4077af6 100644 --- a/hierarchicalforecast/examples/australiandomestictourism-bootstraped-intervals.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourism-bootstraped-intervals.html.mdx @@ -74,7 +74,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can generate: 1. `Y_df`: the hierarchical structured series $\mathbf{y}_{[a,b]\tau}$ 2. `S_df`: the aggregation constraings dataframe with $S_{[a,b]}$ 3. `tags`: a list @@ -122,7 +122,7 @@ array(['Australia/Business', 'Australia/Holiday', 'Australia/Other', ``` We can visualize the `S_df` dataframe and `Y_df` using the -[`HierarchicalPlot`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#hierarchicalplot) +[`HierarchicalPlot`](src/utils.html#hierarchicalplot) class as follows. @@ -197,16 +197,16 @@ Y_fitted_df = fcst.forecast_fitted_values() ## Reconcile Base Forecasts The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. Since the hierarchy structure is not strict, we can’t use methods such as -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown) +[`TopDown`](src/methods.html#topdown) or -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout). +[`MiddleOut`](src/methods.html#middleout). In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). If you want to calculate prediction intervals, you have to use the `level` argument as follows and set `intervals_method='bootstrap'`. diff --git a/hierarchicalforecast/examples/australiandomestictourism-intervals.html.mdx b/hierarchicalforecast/examples/australiandomestictourism-intervals.html.mdx index 849bd4ff..3d47d162 100644 --- a/hierarchicalforecast/examples/australiandomestictourism-intervals.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourism-intervals.html.mdx @@ -74,7 +74,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can generate: 1. `Y_df`: the hierarchical structured series $\mathbf{y}_{[a,b]\tau}$ 2. `S_df`: the aggregation constraings dataframe with $S_{[a,b]}$ 3. `tags`: a list @@ -122,7 +122,7 @@ array(['Australia/Business', 'Australia/Holiday', 'Australia/Other', ``` We can visualize the `S` matrix and the data using the -[`HierarchicalPlot`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#hierarchicalplot) +[`HierarchicalPlot`](src/utils.html#hierarchicalplot) class as follows. @@ -197,16 +197,16 @@ Y_fitted_df = fcst.forecast_fitted_values() ## Reconcile forecasts The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. Since the hierarchy structure is not strict, we can’t use methods such as -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown) +[`TopDown`](src/methods.html#topdown) or -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout). +[`MiddleOut`](src/methods.html#middleout). In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). If you want to calculate prediction intervals, you have to use the `level` argument as follows. diff --git a/hierarchicalforecast/examples/australiandomestictourism-multimodel.html.mdx b/hierarchicalforecast/examples/australiandomestictourism-multimodel.html.mdx index e111eac8..145ef1df 100644 --- a/hierarchicalforecast/examples/australiandomestictourism-multimodel.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourism-multimodel.html.mdx @@ -20,7 +20,7 @@ from `StatsForecast`, machine learning models such as `HistGradientBoostingRegressor` using `MLForecast`, and neural network models like `NBEATS` from `NeuralForecast`. After generating these base forecasts, we will reconcile them using -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup), +[`BottomUp`](src/methods.html#bottomup), `MinTrace(mint_shrink)`, `TopDown(forecast_proportions)` reconciliators from `HierarchicalForecast`. @@ -80,7 +80,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can get the full set of time series. @@ -178,7 +178,7 @@ models = { To fit each model and create forecasts with it, we loop over the timeseries that are present in each level of the hierarchy, using the `tags` we created earlier using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function. @@ -296,9 +296,9 @@ Y_hat_df.head(10) | 9 | Australia/ACT | 2016-04-01 | NaN | 548.060532 | NaN | 548.060532 | We are now ready to make the forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup), +[`BottomUp`](src/methods.html#bottomup), `MinTrace(mint_shrink)`, `TopDown(forecast_proportions)` reconcilers. @@ -336,7 +336,7 @@ Y_rec_df.head() ## 4. Evaluation The `HierarchicalForecast` package includes an -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies. To evaluate models we use `mase` metric and compare it to base predictions. @@ -383,7 +383,7 @@ We find that: upper levels of the hierarchy, reducing the MASE from 1.59 (base forecast) to just 0.44. - **BottomUp for Country/State/Region and Overall**: The - [`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) + [`BottomUp`](src/methods.html#bottomup) method preserves only the NBEATS forecast of the most granular **Country/State/Regions** level, and aggregates those forecasts for the upper levels. It yields the **best Overall MASE score**. @@ -404,10 +404,10 @@ In this example we fitted: We then combined the results into a single prediction. For the reconciliation of the forecasts, we used -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) with three different methods: -- [`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +- [`BottomUp`](src/methods.html#bottomup) - `MinTrace(method='mint_shrink')` - `TopDown(method='forecast_proportions')` diff --git a/hierarchicalforecast/examples/australiandomestictourism-permbu-intervals.html.mdx b/hierarchicalforecast/examples/australiandomestictourism-permbu-intervals.html.mdx index 935806ec..090580d3 100644 --- a/hierarchicalforecast/examples/australiandomestictourism-permbu-intervals.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourism-permbu-intervals.html.mdx @@ -71,7 +71,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can get the full set of time series. @@ -119,7 +119,7 @@ array(['Australia/ACT', 'Australia/New South Wales', ``` We can visualize the `S` matrix and the data using the -[`HierarchicalPlot`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#hierarchicalplot) +[`HierarchicalPlot`](src/utils.html#hierarchicalplot) class as follows. @@ -194,11 +194,11 @@ Y_fitted_df = fcst.forecast_fitted_values() ## Reconcile forecasts and compute prediction intervals using PERMBU The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). If you want to calculate prediction intervals, you have to use the `level` argument as follows and also `intervals_method='permbu'`. diff --git a/hierarchicalforecast/examples/australiandomestictourism.html.mdx b/hierarchicalforecast/examples/australiandomestictourism.html.mdx index afbd2960..6d3ffa31 100644 --- a/hierarchicalforecast/examples/australiandomestictourism.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourism.html.mdx @@ -86,7 +86,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can get the full set of time series. @@ -190,16 +190,16 @@ Y_fitted_df = fcst.forecast_fitted_values() ## 3. Reconcile forecasts The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. Since the hierarchy structure is not strict, we can’t use methods such as -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown) +[`TopDown`](src/methods.html#topdown) or -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout). +[`MiddleOut`](src/methods.html#middleout). In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). ```python @@ -236,7 +236,7 @@ Y_rec_df.head() ## 4. Evaluation The `HierarchicalForecast` package includes an -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies and also is capable of compute scaled metrics compared to a benchmark model. diff --git a/hierarchicalforecast/examples/australiandomestictourismcrosstemporal.html.mdx b/hierarchicalforecast/examples/australiandomestictourismcrosstemporal.html.mdx index b89551a2..cdf2b6e2 100644 --- a/hierarchicalforecast/examples/australiandomestictourismcrosstemporal.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourismcrosstemporal.html.mdx @@ -89,7 +89,7 @@ spec = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can get the full set of time series. @@ -174,16 +174,16 @@ Y_fitted_df_cs = fcst.forecast_fitted_values() ### 2d. Reconcile forecasts The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. Since the hierarchy structure is not strict, we can’t use methods such as -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown) +[`TopDown`](src/methods.html#topdown) or -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout). +[`MiddleOut`](src/methods.html#middleout). In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). ```python @@ -240,7 +240,7 @@ spec_temporal = {"year": 4, "semiannual": 2, "quarter": 1} ``` We next compute the temporally aggregated train- and test sets using the -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal) +[`aggregate_temporal`](src/utils.html#aggregate_temporal) function. Note that we have different aggregation matrices `S` for the train- and test set, as the test set contains temporal hierarchies that are not included in the train set. @@ -286,7 +286,7 @@ If you don’t have a test set available, as is usually the case when you’re making forecasts, it is necessary to create a future dataframe that holds the correct bottom-level unique_ids and timestamps so that they can be temporally aggregated. We can use the -[`make_future_dataframe`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#make_future_dataframe) +[`make_future_dataframe`](src/utils.html#make_future_dataframe) helper function for that. @@ -300,7 +300,7 @@ Y_test_df_te_new = make_future_dataframe(Y_train_df_te, freq="QS", h=horizon) ``` `Y_test_df_te_new` can be then used in -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal) +[`aggregate_temporal`](src/utils.html#aggregate_temporal) to construct the temporally aggregated structures: @@ -395,11 +395,11 @@ Y_hat_df_te = pd.concat(Y_hat_dfs_te, ignore_index=True) ### 3c. Reconcile forecasts We can again use the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class to reconcile the forecasts. In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). Note that we have to set `temporal=True` in the `reconcile` function. Note that temporal reconcilation currently isn’t supported for insample @@ -418,7 +418,7 @@ Y_rec_df_te = hrec.reconcile(Y_hat_df=Y_hat_df_te, S_df=S_test_df_te, tags=tags_ ## 4. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies. @@ -505,7 +505,7 @@ than the `Base` forecasts on the `year` aggregated forecasts. Finally, we evaluate cross-temporally. To do so, we first need to obtain the combination of cross-sectional and temporal hierarchies, for which we can use the -[`get_cross_temporal_tags`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#get_cross_temporal_tags) +[`get_cross_temporal_tags`](src/utils.html#get_cross_temporal_tags) helper function. diff --git a/hierarchicalforecast/examples/australiandomestictourismtemporal.html.mdx b/hierarchicalforecast/examples/australiandomestictourismtemporal.html.mdx index 61eabecb..044a64e1 100644 --- a/hierarchicalforecast/examples/australiandomestictourismtemporal.html.mdx +++ b/hierarchicalforecast/examples/australiandomestictourismtemporal.html.mdx @@ -111,7 +111,7 @@ spec_temporal = {"year": 4, "semiannual": 2, "quarter": 1} ``` We next compute the temporally aggregated train- and test sets using the -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal) +[`aggregate_temporal`](src/utils.html#aggregate_temporal) function. Note that we have different aggregation matrices `S` for the train- and test set, as the test set contains temporal hierarchies that are not included in the train set. @@ -200,7 +200,7 @@ If you don’t have a test set available, as is usually the case when you’re making forecasts, it is necessary to create a future dataframe that holds the correct bottom-level unique_ids and timestamps so that they can be temporally aggregated. We can use the -[`make_future_dataframe`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#make_future_dataframe) +[`make_future_dataframe`](src/utils.html#make_future_dataframe) helper function for that. @@ -214,7 +214,7 @@ Y_test_df_new = make_future_dataframe(Y_train_df, freq="QS", h=horizon) ``` `Y_test_df_new` can be then used in -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal) +[`aggregate_temporal`](src/utils.html#aggregate_temporal) to construct the temporally aggregated structures: @@ -336,11 +336,11 @@ Y_hat_df = pd.concat(Y_hat_dfs, ignore_index=True) ### 3c. Reconcile forecasts We can use the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class to reconcile the forecasts. In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). Note that we have to set `temporal=True` in the `reconcile` function. Note that temporal reconcilation currently isn’t supported for insample @@ -369,7 +369,7 @@ Y_rec_df = hrec.reconcile(Y_hat_df=Y_hat_df, ## 4. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies. We evaluate the temporally aggregated forecasts *across all temporal diff --git a/hierarchicalforecast/examples/australianprisonpopulation.html.mdx b/hierarchicalforecast/examples/australianprisonpopulation.html.mdx index 69f77855..746d1aa6 100644 --- a/hierarchicalforecast/examples/australianprisonpopulation.html.mdx +++ b/hierarchicalforecast/examples/australianprisonpopulation.html.mdx @@ -78,7 +78,7 @@ hiers = [ ``` Using the -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function from `HierarchicalForecast` we can get the full set of time series. @@ -221,16 +221,16 @@ Y_train_df ## 3. Reconcile forecasts The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. Since the hierarchy structure is not strict, we can’t use methods such as -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown) +[`TopDown`](src/methods.html#topdown) or -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout). +[`MiddleOut`](src/methods.html#middleout). In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace). +[`MinTrace`](src/methods.html#mintrace). ```python @@ -266,7 +266,7 @@ Y_rec_df.head() ## 4. Evaluation The `HierarchicalForecast` package includes the -[`HierarchicalEvaluation`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#hierarchicalevaluation) +[`HierarchicalEvaluation`](src/evaluation.html#hierarchicalevaluation) class to evaluate the different hierarchies and also is capable of compute scaled metrics compared to a benchmark model. diff --git a/hierarchicalforecast/examples/introduction.html.mdx b/hierarchicalforecast/examples/introduction.html.mdx index 7b6fa1da..20cd30c2 100644 --- a/hierarchicalforecast/examples/introduction.html.mdx +++ b/hierarchicalforecast/examples/introduction.html.mdx @@ -99,15 +99,15 @@ $$\tilde{\mathbf{y}}_{[a,b],\tau} = \mathbf{S}_{[a,b][b]} \mathbf{P}_{[b][a,b]} The HierarchicalForecast library offers a Python collection of reconciliation methods, datasets, evaluation and visualization tools for the task. Among its available reconciliation methods we have -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup), -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown), -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout), -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace), -[`ERM`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#erm). +[`BottomUp`](src/methods.html#bottomup), +[`TopDown`](src/methods.html#topdown), +[`MiddleOut`](src/methods.html#middleout), +[`MinTrace`](src/methods.html#mintrace), +[`ERM`](src/methods.html#erm). Among its probabilistic coherent methods we have -[`Normality`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#normality), -[`Bootstrap`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#bootstrap), -[`PERMBU`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#permbu). +[`Normality`](src/probabilistic_methods.html#normality), +[`Bootstrap`](src/probabilistic_methods.html#bootstrap), +[`PERMBU`](src/probabilistic_methods.html#permbu). ## 3. Minimal Example diff --git a/hierarchicalforecast/examples/localglobalaggregation.html.mdx b/hierarchicalforecast/examples/localglobalaggregation.html.mdx index 1fbd946a..c8fbaf92 100644 --- a/hierarchicalforecast/examples/localglobalaggregation.html.mdx +++ b/hierarchicalforecast/examples/localglobalaggregation.html.mdx @@ -100,7 +100,7 @@ In global aggregation, we examine all unique timestamps across all timeseries, and base our temporal aggregations on the unique list of timestamps across all timeseries. We can specify the aggregation type by setting the `aggregation_type` attritbue in -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal). +[`aggregate_temporal`](src/utils.html#aggregate_temporal). ```python diff --git a/hierarchicalforecast/examples/m3withthief.html.mdx b/hierarchicalforecast/examples/m3withthief.html.mdx index 8c7a5621..6801f81f 100644 --- a/hierarchicalforecast/examples/m3withthief.html.mdx +++ b/hierarchicalforecast/examples/m3withthief.html.mdx @@ -112,7 +112,7 @@ spec_temporal_quarterly = {"yearly": 4, "semiannually": 2, "quarterly": 1} ``` We next compute the temporally aggregated train- and test sets using the -[`aggregate_temporal`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate_temporal) +[`aggregate_temporal`](src/utils.html#aggregate_temporal) function. Note that we have different aggregation matrices `S` for the train- and test set, as the test set contains temporal hierarchies that are not included in the train set. @@ -224,9 +224,9 @@ for tags_train, tags_test, Y_train, Y_test in zip([tags_monthly_train, tags_quar ### 2c. Reconcile forecasts We can use the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class to reconcile the forecasts. In this example we use -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup) +[`BottomUp`](src/methods.html#bottomup) and `MinTrace(wls_struct)`. The latter is the ‘structural scaling’ method introduced in [Forecasting with temporal hierarchies](https://robjhyndman.com/publications/temporal-hierarchies/). @@ -258,7 +258,7 @@ for Y_hat, S, tags in zip(Y_hats, ## 3. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies. We evaluate the temporally aggregated forecasts *across all temporal diff --git a/hierarchicalforecast/examples/nonnegativereconciliation.html.mdx b/hierarchicalforecast/examples/nonnegativereconciliation.html.mdx index da20d016..dee950e0 100644 --- a/hierarchicalforecast/examples/nonnegativereconciliation.html.mdx +++ b/hierarchicalforecast/examples/nonnegativereconciliation.html.mdx @@ -201,7 +201,7 @@ Y_hat_df.query('AutoETS < 0') The following cell makes the previous forecasts coherent and nonnegative using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. @@ -275,7 +275,7 @@ Y_rec_df.query('`AutoETS/MinTrace_method-ols` < 0') ## 4. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies. We use `utilsforecast` to compute the mean absolute error. diff --git a/hierarchicalforecast/examples/tourismsmall.html.mdx b/hierarchicalforecast/examples/tourismsmall.html.mdx index ac8e10a6..078d5f73 100644 --- a/hierarchicalforecast/examples/tourismsmall.html.mdx +++ b/hierarchicalforecast/examples/tourismsmall.html.mdx @@ -131,17 +131,17 @@ Y_hat_df = fcst.forecast(df=Y_train_df, h=group.horizon) ## 4. Hierarchical reconciliation The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. The used methods to make the forecasts coherent are: -- [`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup): +- [`BottomUp`](src/methods.html#bottomup): The reconciliation of the method is a simple addition to the upper levels. -- [`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown): +- [`TopDown`](src/methods.html#topdown): The second method constrains the base-level predictions to the top-most aggregate-level serie and then distributes it to the disaggregate series through the use of proportions. -- [`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout): +- [`MiddleOut`](src/methods.html#middleout): Anchors the base predictions in a middle level. @@ -165,7 +165,7 @@ Y_rec_df = hrec.reconcile(Y_hat_df=Y_hat_df, Y_df=Y_train_df, S_df=S_df, tags=ta ## 5. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies and we can use utilsforecast to compute the mean absolute error relative to a baseline model. diff --git a/hierarchicalforecast/examples/tourismsmallpolars.html.mdx b/hierarchicalforecast/examples/tourismsmallpolars.html.mdx index 9164aeff..f401b6cd 100644 --- a/hierarchicalforecast/examples/tourismsmallpolars.html.mdx +++ b/hierarchicalforecast/examples/tourismsmallpolars.html.mdx @@ -135,17 +135,17 @@ Y_hat_df = fcst.forecast(df=Y_train_df, h=group.horizon) ## 4. Hierarchical reconciliation The following cell makes the previous forecasts coherent using the -[`HierarchicalReconciliation`](https://Nixtla.github.io/hierarchicalforecast/src/core.html#hierarchicalreconciliation) +[`HierarchicalReconciliation`](src/core.html#hierarchicalreconciliation) class. The used methods to make the forecasts coherent are: -- [`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup): +- [`BottomUp`](src/methods.html#bottomup): The reconciliation of the method is a simple addition to the upper levels. -- [`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown): +- [`TopDown`](src/methods.html#topdown): The second method constrains the base-level predictions to the top-most aggregate-level serie and then distributes it to the disaggregate series through the use of proportions. -- [`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout): +- [`MiddleOut`](src/methods.html#middleout): Anchors the base predictions in a middle level. @@ -169,7 +169,7 @@ Y_rec_df = hrec.reconcile(Y_hat_df=Y_hat_df, Y_df=Y_train_df, S_df=S_df, tags=ta ## 5. Evaluation The `HierarchicalForecast` package includes the -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function to evaluate the different hierarchies and we can use utilsforecast to compute the mean absolute error relative to a baseline model. diff --git a/hierarchicalforecast/index.html.mdx b/hierarchicalforecast/index.html.mdx index e30708ac..5c682113 100644 --- a/hierarchicalforecast/index.html.mdx +++ b/hierarchicalforecast/index.html.mdx @@ -11,17 +11,17 @@ algorithms capable of coherent forecasts. **HierarchicalForecast** offers a collection of cross-sectional and temporal reconciliation methods, including -[`BottomUp`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#bottomup), -[`TopDown`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#topdown), -[`MiddleOut`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#middleout), -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace) +[`BottomUp`](src/methods.html#bottomup), +[`TopDown`](src/methods.html#topdown), +[`MiddleOut`](src/methods.html#middleout), +[`MinTrace`](src/methods.html#mintrace) and -[`ERM`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#erm), +[`ERM`](src/methods.html#erm), as well as probabilistic coherent predictions including -[`Normality`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#normality), -[`Bootstrap`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#bootstrap), +[`Normality`](src/probabilistic_methods.html#normality), +[`Bootstrap`](src/probabilistic_methods.html#bootstrap), and -[`PERMBU`](https://Nixtla.github.io/hierarchicalforecast/src/probabilistic_methods.html#permbu). +[`PERMBU`](src/probabilistic_methods.html#permbu). ## 🎊 Features diff --git a/hierarchicalforecast/src/evaluation.html.mdx b/hierarchicalforecast/src/evaluation.html.mdx index 14ec05c8..8a9ceb63 100644 --- a/hierarchicalforecast/src/evaluation.html.mdx +++ b/hierarchicalforecast/src/evaluation.html.mdx @@ -6,7 +6,7 @@ title: Hierarchical Evaluation To assist the evaluation of hierarchical forecasting systems, we make available an -[`evaluate`](https://Nixtla.github.io/hierarchicalforecast/src/evaluation.html#evaluate) +[`evaluate`](src/evaluation.html#evaluate) function that can be used in combination with loss functions from `utilsforecast.losses`. diff --git a/hierarchicalforecast/src/methods.html.mdx b/hierarchicalforecast/src/methods.html.mdx index d7d54892..4453bc02 100644 --- a/hierarchicalforecast/src/methods.html.mdx +++ b/hierarchicalforecast/src/methods.html.mdx @@ -1285,7 +1285,7 @@ this method is defined by: $$ \mathbf{P} = \left(\mathbf{S}^{\intercal}\Sigma_{h}^{\dagger}\mathbf{S}\right)^{-1}\mathbf{S}^{\intercal}\Sigma^{\dagger}_{h}$$ where $\Sigma_{h}^{\dagger}$ denotes the variance pseudo-inverse. The method was later proven equivalent to -[`MinTrace`](https://Nixtla.github.io/hierarchicalforecast/src/methods.html#mintrace) +[`MinTrace`](src/methods.html#mintrace) variants. **Parameters:**
`method`: str, allowed optimal combination methods: diff --git a/hierarchicalforecast/src/utils.html.mdx b/hierarchicalforecast/src/utils.html.mdx index d4fb56fa..fe32ff90 100644 --- a/hierarchicalforecast/src/utils.html.mdx +++ b/hierarchicalforecast/src/utils.html.mdx @@ -6,7 +6,7 @@ title: Aggregation/Visualization Utils The `HierarchicalForecast` package contains utility functions to wrangle and visualize hierarchical series datasets. The -[`aggregate`](https://Nixtla.github.io/hierarchicalforecast/src/utils.html#aggregate) +[`aggregate`](src/utils.html#aggregate) function of the module allows you to create a hierarchy from categorical variables representing the structure levels, returning also the aggregation contraints matrix $\mathbf{S}$. diff --git a/mlforecast/core.html.mdx b/mlforecast/core.html.mdx index f87fe018..6c4046e9 100644 --- a/mlforecast/core.html.mdx +++ b/mlforecast/core.html.mdx @@ -90,7 +90,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source *Utility class for storing and transforming time series data.* The -[`TimeSeries`](https://Nixtla.github.io/mlforecast/core.html#timeseries) +[`TimeSeries`](core.html#timeseries) class takes care of defining the transformations to be performed (`lags`, `lag_transforms` and `date_features`). The transformations can be computed using multithreading if `num_threads > 1`. @@ -143,7 +143,7 @@ test_eq( Note that for `lags` we define the transformation as the identity function applied to its corresponding lag. This is because -[`_transform_series`](https://Nixtla.github.io/mlforecast/grouped_array.html#_transform_series) +[`_transform_series`](grouped_array.html#_transform_series) takes the lag as an argument and shifts the array before computing the transformation. @@ -228,7 +228,7 @@ pd.testing.assert_frame_equal( ``` If you pass `static_features` to -[`TimeSeries.fit_transform`](https://Nixtla.github.io/mlforecast/core.html#timeseries.fit_transform) +[`TimeSeries.fit_transform`](core.html#timeseries.fit_transform) then only these are kept. ```python @@ -274,7 +274,7 @@ test_eq(df.shape[0], series.shape[0] - (2 + 13) * ts.ga.n_groups) test_eq(ts.ga.data.size, ts.ga.n_groups * keep_last_n) ``` -[`TimeSeries.fit_transform`](https://Nixtla.github.io/mlforecast/core.html#timeseries.fit_transform) +[`TimeSeries.fit_transform`](core.html#timeseries.fit_transform) requires that the *y* column doesn’t have any null values. This is because the transformations could propagate them forward, so if you have null values in the *y* column you’ll get an error. @@ -306,7 +306,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source > ``` Once we have a trained model we can use -[`TimeSeries.predict`](https://Nixtla.github.io/mlforecast/core.html#timeseries.predict) +[`TimeSeries.predict`](core.html#timeseries.predict) passing the model and the horizon to get the predictions back. ```python diff --git a/mlforecast/docs/getting-started/end_to_end_walkthrough.html.mdx b/mlforecast/docs/getting-started/end_to_end_walkthrough.html.mdx index 237470e8..5ab3be78 100644 --- a/mlforecast/docs/getting-started/end_to_end_walkthrough.html.mdx +++ b/mlforecast/docs/getting-started/end_to_end_walkthrough.html.mdx @@ -59,12 +59,12 @@ fig = plot_series(df, max_insample_length=24 * 14) ![](/mlforecast/docs/getting-started/../../figs/end_to_end_walkthrough__eda.png) We can use the -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) method to explore different transformations. It looks like these series have a strong seasonality on the hour of the day, so we can subtract the value from the same hour in the previous day to remove it. This can be done with the -[`mlforecast.target_transforms.Differences`](https://Nixtla.github.io/mlforecast/target_transforms.html#differences) +[`mlforecast.target_transforms.Differences`](target_transforms.html#differences) transformer, which we pass through `target_transforms`. ```python @@ -342,7 +342,7 @@ np.testing.assert_allclose(preds['Naive'], last_vals['y']) Once you’ve decided the features, transformations and models that you want to use you can use the -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) method instead, which will do the preprocessing and then train the models. The models can be specified as a list (which will name them by using their class name and an index if there are repeated classes) or as @@ -416,9 +416,9 @@ fig = plot_series(df, preds, max_insample_length=24 * 7) ## Saving and loading The MLForecast class has the -[`MLForecast.save`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.save) +[`MLForecast.save`](forecast.html#mlforecast.save) and -[`MLForecast.load`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.load) +[`MLForecast.load`](forecast.html#mlforecast.load) to store and then load the forecast object. ```python @@ -435,7 +435,7 @@ with tempfile.TemporaryDirectory() as tmpdir: After you’ve trained a forecast object you can save and load it with the previous methods. If by the time you want to use it you already know the following values of the target you can use the -[`MLForecast.update`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.update) +[`MLForecast.update`](forecast.html#mlforecast.update) method to incorporate these, which will allow you to use these new values when computing predictions. @@ -490,7 +490,7 @@ using them to predict a validation set and measuring their performance. Since our data depends on time, we make our splits by removing the last portions of the series and using them as validation sets. This process is implemented in -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation). +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation). ```python fcst = MLForecast( @@ -602,11 +602,11 @@ dtype: float64 ### LightGBMCV In the same spirit of estimating our model’s performance, -[`LightGBMCV`](https://Nixtla.github.io/mlforecast/lgb_cv.html#lightgbmcv) +[`LightGBMCV`](lgb_cv.html#lightgbmcv) allows us to train a few [LightGBM](https://github.com/microsoft/LightGBM) models on different partitions of the data. The main differences with -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation) +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation) are: - It can only train LightGBM models. @@ -688,9 +688,9 @@ You can use this class to quickly try different configurations of features and hyperparameters. Once you’ve found a combination that works you can train a model with those features and hyperparameters on all the data by creating an -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object from the -[`LightGBMCV`](https://Nixtla.github.io/mlforecast/lgb_cv.html#lightgbmcv) +[`LightGBMCV`](lgb_cv.html#lightgbmcv) one as follows: ```python diff --git a/mlforecast/docs/getting-started/quick_start_distributed.html.mdx b/mlforecast/docs/getting-started/quick_start_distributed.html.mdx index a0ea3dbf..55131100 100644 --- a/mlforecast/docs/getting-started/quick_start_distributed.html.mdx +++ b/mlforecast/docs/getting-started/quick_start_distributed.html.mdx @@ -6,15 +6,15 @@ title: Quick start (distributed) The -[`DistributedMLForecast`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast) +[`DistributedMLForecast`](distributed.forecast.html#distributedmlforecast) class is a high level abstraction that encapsulates all the steps in the pipeline (preprocessing, fitting the model and computing predictions) and applies them in a distributed way. The different things that you need to use -[`DistributedMLForecast`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast) +[`DistributedMLForecast`](distributed.forecast.html#distributedmlforecast) (as opposed to -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast)) +[`MLForecast`](forecast.html#mlforecast)) are: 1. You need to set up a cluster. We currently support dask, ray and @@ -69,7 +69,7 @@ have more partitions than workers make sure to set `num_threads=1` to avoid having nested parallelism. The required input format is the same as for -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast), +[`MLForecast`](forecast.html#mlforecast), except that it’s a `dask.dataframe.DataFrame` instead of a `pandas.Dataframe`. @@ -97,9 +97,9 @@ partitioned_series In order to perform distributed forecasting, we need to use a model that is able to train in a distributed way using `dask`. The current implementations are in -[`DaskLGBMForecast`](https://Nixtla.github.io/mlforecast/distributed.models.dask.lgb.html#dasklgbmforecast) +[`DaskLGBMForecast`](distributed.models.dask.lgb.html#dasklgbmforecast) and -[`DaskXGBForecast`](https://Nixtla.github.io/mlforecast/distributed.models.dask.xgb.html#daskxgbforecast) +[`DaskXGBForecast`](distributed.models.dask.xgb.html#daskxgbforecast) which are just wrappers around the native implementations. ```python @@ -118,7 +118,7 @@ models = [ ### Training Once we have our models we instantiate a -[`DistributedMLForecast`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast) +[`DistributedMLForecast`](distributed.forecast.html#distributedmlforecast) object defining our features. We can then call `fit` on this object passing our dask dataframe. @@ -160,7 +160,7 @@ preds.head() ### Saving and loading Once you’ve trained your model you can use the -[`DistributedMLForecast.save`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast.save) +[`DistributedMLForecast.save`](distributed.forecast.html#distributedmlforecast.save) method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. @@ -290,7 +290,7 @@ workers make sure to set `num_threads=1` to avoid having nested parallelism. The required input format is the same as for -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast), +[`MLForecast`](forecast.html#mlforecast), i.e. it should have at least an id column, a time column and a target column. @@ -307,9 +307,9 @@ spark_series = spark.createDataFrame(train).repartitionByRange(numPartitions, 'u In order to perform distributed forecasting, we need to use a model that is able to train in a distributed way using `spark`. The current implementations are in -[`SparkLGBMForecast`](https://Nixtla.github.io/mlforecast/distributed.models.spark.lgb.html#sparklgbmforecast) +[`SparkLGBMForecast`](distributed.models.spark.lgb.html#sparklgbmforecast) and -[`SparkXGBForecast`](https://Nixtla.github.io/mlforecast/distributed.models.spark.xgb.html#sparkxgbforecast) +[`SparkXGBForecast`](distributed.models.spark.xgb.html#sparkxgbforecast) which are just wrappers around the native implementations. ```python @@ -369,7 +369,7 @@ preds.head() ### Saving and loading Once you’ve trained your model you can use the -[`DistributedMLForecast.save`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast.save) +[`DistributedMLForecast.save`](distributed.forecast.html#distributedmlforecast.save) method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. @@ -499,7 +499,7 @@ than workers make sure to set `num_threads=1` to avoid having nested parallelism. The required input format is the same as for -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast), +[`MLForecast`](forecast.html#mlforecast), i.e. it should have at least an id column, a time column and a target column. @@ -532,7 +532,7 @@ models = [ To control the number of partitions to use using Ray, we have to include `num_partitions` to -[`DistributedMLForecast`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast). +[`DistributedMLForecast`](distributed.forecast.html#distributedmlforecast). ```python num_partitions = 4 @@ -575,7 +575,7 @@ preds.head() ### Saving and loading Once you’ve trained your model you can use the -[`DistributedMLForecast.save`](https://Nixtla.github.io/mlforecast/distributed.forecast.html#distributedmlforecast.save) +[`DistributedMLForecast.save`](distributed.forecast.html#distributedmlforecast.save) method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. diff --git a/mlforecast/docs/getting-started/quick_start_local.html.mdx b/mlforecast/docs/getting-started/quick_start_local.html.mdx index 440759ec..41e67102 100644 --- a/mlforecast/docs/getting-started/quick_start_local.html.mdx +++ b/mlforecast/docs/getting-started/quick_start_local.html.mdx @@ -8,13 +8,13 @@ title: Quick start (local) ## Main concepts The main component of mlforecast is the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) class, which abstracts away: - Feature engineering and model training through - [`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) + [`MLForecast.fit`](forecast.html#mlforecast.fit) - Feature updates and multi step ahead predictions through - [`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict) + [`MLForecast.predict`](forecast.html#mlforecast.predict) ## Data format diff --git a/mlforecast/docs/how-to-guides/analyzing_models.html.mdx b/mlforecast/docs/how-to-guides/analyzing_models.html.mdx index 136bbec1..e0b64d87 100644 --- a/mlforecast/docs/how-to-guides/analyzing_models.html.mdx +++ b/mlforecast/docs/how-to-guides/analyzing_models.html.mdx @@ -56,7 +56,7 @@ MLForecast(models=[lr], freq=, lag_features=['lag1'], date_features=['dayof ``` What -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) does is save the required data for the predict step and also train the models (in this case the linear regression). The trained models are available in the `MLForecast.models_` attribute, which is a dictionary @@ -92,7 +92,7 @@ import shap ### Training set If you need to generate the training data you can use -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess). +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess). ```python prep = fcst.preprocess(series) @@ -165,7 +165,7 @@ preds.head() | 4 | id_4 | 2001-01-08 | 3.524532 | You can now retrieve the features by using -[`SaveFeatures.get_features`](https://Nixtla.github.io/mlforecast/callbacks.html#savefeatures.get_features) +[`SaveFeatures.get_features`](callbacks.html#savefeatures.get_features) ```python features = save_feats.get_features() diff --git a/mlforecast/docs/how-to-guides/cross_validation.html.mdx b/mlforecast/docs/how-to-guides/cross_validation.html.mdx index e6afac8b..36081a60 100644 --- a/mlforecast/docs/how-to-guides/cross_validation.html.mdx +++ b/mlforecast/docs/how-to-guides/cross_validation.html.mdx @@ -10,7 +10,7 @@ title: Cross validation > **Prerequesites** > > This tutorial assumes basic familiarity with -> [`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast). +> [`MLForecast`](forecast.html#mlforecast). > For a minimal example visit the [Quick Start](quick_start_local.html) ## Introduction @@ -45,7 +45,7 @@ hourly dataset. ## Install libraries We assume that you have -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) already installed. If not, check this guide for instructions on [how to install MLForecast](../getting-started/install.html). @@ -78,7 +78,7 @@ Y_df.head() | 4 | H1 | 5 | 511.0 | The input to -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) is a data frame in [long format](https://www.theanalysisfactor.com/wide-and-long-data/) with three columns: `unique_id`, `ds` and `y`: @@ -136,7 +136,7 @@ mlf = MLForecast( ## Perform time series cross-validation Once the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object has been instantiated, we can use the [cross_validation method](../../forecast.html#mlforecast.cross_validation). diff --git a/mlforecast/docs/how-to-guides/custom_training.html.mdx b/mlforecast/docs/how-to-guides/custom_training.html.mdx index bd92fe8c..11ddc050 100644 --- a/mlforecast/docs/how-to-guides/custom_training.html.mdx +++ b/mlforecast/docs/how-to-guides/custom_training.html.mdx @@ -46,7 +46,7 @@ fcst = MLForecast( ## Generate training set Use -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) to generate the training data. ```python @@ -71,7 +71,7 @@ y = prep['y'] Since we don’t want to do anything special in our training process for the linear regression, we can just call -[`MLForecast.fit_models`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit_models) +[`MLForecast.fit_models`](forecast.html#mlforecast.fit_models) ```python fcst.fit_models(X, y) @@ -132,7 +132,7 @@ fcst.models_ ``` And now when calling -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict), +[`MLForecast.predict`](forecast.html#mlforecast.predict), mlforecast will use those models to compute the forecasts. ```python diff --git a/mlforecast/docs/how-to-guides/exogenous_features.html.mdx b/mlforecast/docs/how-to-guides/exogenous_features.html.mdx index 3d0dfbe5..040f1a83 100644 --- a/mlforecast/docs/how-to-guides/exogenous_features.html.mdx +++ b/mlforecast/docs/how-to-guides/exogenous_features.html.mdx @@ -37,14 +37,14 @@ target. Any extra columns you have, like `static_0` and `product_id` here are considered to be static and are replicated when constructing the features for the next timestamp. You can disable this by passing `static_features` to -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) or -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit), +[`MLForecast.fit`](forecast.html#mlforecast.fit), which will only keep the columns you define there as static. Keep in mind that all features in your input dataframe will be used for training, so you’ll have to provide the future values of exogenous features to -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict) +[`MLForecast.predict`](forecast.html#mlforecast.predict) through the `X_df` argument. Consider the following example. Suppose that we have a prices catalog @@ -80,9 +80,9 @@ series_with_prices.head() | 4 | id_00 | 2000-10-09 | 344.940404 | 79 | 45 | 0.423655 | This dataframe will be passed to -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) (or -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess)). +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess)). However, since the price is dynamic we have to tell that method that only `static_0` and `product_id` are static. @@ -125,7 +125,7 @@ fcst.ts.features_order_ ``` So in order to update the price in each timestep we just call -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict) +[`MLForecast.predict`](forecast.html#mlforecast.predict) with our forecast horizon and pass the prices catalog through `X_df`. ```python diff --git a/mlforecast/docs/how-to-guides/hyperparameter_optimization.html.mdx b/mlforecast/docs/how-to-guides/hyperparameter_optimization.html.mdx index a7fa8684..b803d9bd 100644 --- a/mlforecast/docs/how-to-guides/hyperparameter_optimization.html.mdx +++ b/mlforecast/docs/how-to-guides/hyperparameter_optimization.html.mdx @@ -196,12 +196,12 @@ evaluate(preds, group) ### Tuning features The -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) class defines the features to build in its constructor. You can tune the features by providing a function through the `init_config` argument, which will take an optuna trial and produce a configuration to pass to the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) constructor. ```python @@ -240,7 +240,7 @@ evaluate(preds, group) ### Tuning fit parameters The -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) method takes some arguments that could improve the forecasting performance of your models, such as `dropna` and `static_features`. If you want to tune those you can provide a function to the `fit_config` @@ -281,7 +281,7 @@ evaluate(preds, group) After the process has finished the results are available under the `results_` attribute of the -[`AutoMLForecast`](https://Nixtla.github.io/mlforecast/auto.html#automlforecast) +[`AutoMLForecast`](auto.html#automlforecast) object. There will be one result per model and the best configuration can be found under the `config` user attribute. @@ -322,7 +322,7 @@ There is one optimization process per model. This is because different models can make use of different features. So after the optimization process is done for each model the best configuration is used to retrain the model using all of the data. These final models are -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) objects and are saved in the `models_` attribute. ```python @@ -336,7 +336,7 @@ auto_mlf.models_ ## Saving You can use the -[`AutoMLForecast.save`](https://Nixtla.github.io/mlforecast/auto.html#automlforecast.save) +[`AutoMLForecast.save`](auto.html#automlforecast.save) method to save the best models found. This produces one directory per model. @@ -351,7 +351,7 @@ with tempfile.TemporaryDirectory() as tmpdir: ``` Since each model is an -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object you can load it by itself. ```python diff --git a/mlforecast/docs/how-to-guides/lag_transforms_guide.html.mdx b/mlforecast/docs/how-to-guides/lag_transforms_guide.html.mdx index 08e1b42d..21685d2f 100644 --- a/mlforecast/docs/how-to-guides/lag_transforms_guide.html.mdx +++ b/mlforecast/docs/how-to-guides/lag_transforms_guide.html.mdx @@ -47,7 +47,7 @@ fcst = MLForecast( Once you define your transformations you can see what they look like with -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess). +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess). ```python fcst.preprocess(data).head(2) @@ -61,7 +61,7 @@ fcst.preprocess(data).head(2) ### Extending the built-in transformations You can compose the built-in transformations by using the -[`Combine`](https://Nixtla.github.io/mlforecast/lag_transforms.html#combine) +[`Combine`](lag_transforms.html#combine) class, which takes two transformations and an operator. ```python @@ -104,9 +104,9 @@ np.testing.assert_allclose( ``` If you want one of the transformations in -[`Combine`](https://Nixtla.github.io/mlforecast/lag_transforms.html#combine) +[`Combine`](lag_transforms.html#combine) to be applied to a different lag you can use the -[`Offset`](https://Nixtla.github.io/mlforecast/lag_transforms.html#offset) +[`Offset`](lag_transforms.html#offset) class, which will apply the offset first and then the transformation. ```python @@ -162,9 +162,9 @@ predict step they can very slow, because we have to call the function again on the complete history and just keep the last value, so if performance is a concern you should try to use the built-in ones or set `keep_last_n` in -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) or -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) to the minimum number of samples that your transformations require. ```python diff --git a/mlforecast/docs/how-to-guides/one_model_per_horizon.html.mdx b/mlforecast/docs/how-to-guides/one_model_per_horizon.html.mdx index fd2674dd..64d4dcf9 100644 --- a/mlforecast/docs/how-to-guides/one_model_per_horizon.html.mdx +++ b/mlforecast/docs/how-to-guides/one_model_per_horizon.html.mdx @@ -16,10 +16,10 @@ value at each specific step, i.e. one model predicts the next value, another one predicts the value two steps ahead and so on. This can be very time consuming but can also provide better results. If you want to use this approach you can specify `max_horizon` in -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit), +[`MLForecast.fit`](forecast.html#mlforecast.fit), which will train that many models and each model will predict its corresponding horizon when you call -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict). +[`MLForecast.predict`](forecast.html#mlforecast.predict). ## Setup diff --git a/mlforecast/docs/how-to-guides/predict_callbacks.html.mdx b/mlforecast/docs/how-to-guides/predict_callbacks.html.mdx index 430b98f2..bb68bc70 100644 --- a/mlforecast/docs/how-to-guides/predict_callbacks.html.mdx +++ b/mlforecast/docs/how-to-guides/predict_callbacks.html.mdx @@ -44,7 +44,7 @@ def inspect_input(new_x): And now we can pass this function to the `before_predict_callback` argument of -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict). +[`MLForecast.predict`](forecast.html#mlforecast.predict). ```python fcst = MLForecast(lgb.LGBMRegressor(verbosity=-1), freq='D', lags=[1, 2]) @@ -71,7 +71,7 @@ preds Saving the features that are sent as input to the model in each timestamp can be helpful, for example to estimate SHAP values. This can be easily achieved with the -[`SaveFeatures`](https://Nixtla.github.io/mlforecast/callbacks.html#savefeatures) +[`SaveFeatures`](callbacks.html#savefeatures) callback. ```python @@ -103,7 +103,7 @@ When predicting with the recursive strategy (the default) the predictions for each timestamp are used to update the target and recompute the features. If you want to do something to these predictions before that happens you can use the `after_predict_callback` argument of -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict). +[`MLForecast.predict`](forecast.html#mlforecast.predict). ### Increasing predictions values diff --git a/mlforecast/docs/how-to-guides/sample_weights.html.mdx b/mlforecast/docs/how-to-guides/sample_weights.html.mdx index 16490b42..64e1084f 100644 --- a/mlforecast/docs/how-to-guides/sample_weights.html.mdx +++ b/mlforecast/docs/how-to-guides/sample_weights.html.mdx @@ -49,7 +49,7 @@ fcst = MLForecast( ## Forecasting You can provide the `weight_col` argument to -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) to indicate which column should be used as the sample weights. ```python @@ -64,7 +64,7 @@ fcst.fit(series, weight_col='weight').predict(1) ## Cross validation You can provide the `weight_col` argument to -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation) +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation) to indicate which column should be used as the sample weights. ```python diff --git a/mlforecast/docs/how-to-guides/target_transforms_guide.html.mdx b/mlforecast/docs/how-to-guides/target_transforms_guide.html.mdx index 9fb0c08c..22ce848c 100644 --- a/mlforecast/docs/how-to-guides/target_transforms_guide.html.mdx +++ b/mlforecast/docs/how-to-guides/target_transforms_guide.html.mdx @@ -149,7 +149,7 @@ plt.close() There are some transformations that don’t require to learn any parameters, such as applying logarithm for example. These can be easily defined using the -[`GlobalSklearnTransformer`](https://Nixtla.github.io/mlforecast/target_transforms.html#globalsklearntransformer), +[`GlobalSklearnTransformer`](target_transforms.html#globalsklearntransformer), which takes a scikit-learn compatible transformer and applies it to all series. Here’s an example on how to define a transformation that applies logarithm to each value of the series + 1, which can help avoid @@ -194,7 +194,7 @@ plot({'original': serie, 'Log + Differences': log_diffs}, 'target_transforms__lo In order to implement your own target transformation you have to define a class that inherits from -[`mlforecast.target_transforms.BaseTargetTransform`](https://Nixtla.github.io/mlforecast/target_transforms.html#basetargettransform) +[`mlforecast.target_transforms.BaseTargetTransform`](target_transforms.html#basetargettransform) (this takes care of setting the column names as the `id_col`, `time_col` and `target_col` attributes) and implement the `fit_transform` and `inverse_transform` methods. Here’s an example on how to define a diff --git a/mlforecast/docs/how-to-guides/training_with_numpy.html.mdx b/mlforecast/docs/how-to-guides/training_with_numpy.html.mdx index 809f4344..dcf023ba 100644 --- a/mlforecast/docs/how-to-guides/training_with_numpy.html.mdx +++ b/mlforecast/docs/how-to-guides/training_with_numpy.html.mdx @@ -42,7 +42,7 @@ fcst = MLForecast( ``` If you’re using the fit/cross_validation methods from -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) all you have to do to train with numpy arrays is provide the `as_numpy` argument, which will cast the features to an array before passing them to the models. diff --git a/mlforecast/docs/how-to-guides/transfer_learning.html.mdx b/mlforecast/docs/how-to-guides/transfer_learning.html.mdx index f9555d3f..31c1be4f 100644 --- a/mlforecast/docs/how-to-guides/transfer_learning.html.mdx +++ b/mlforecast/docs/how-to-guides/transfer_learning.html.mdx @@ -78,7 +78,7 @@ fig = plot_series(Y_df_M3) ## Model Training Using the -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit) +[`MLForecast.fit`](forecast.html#mlforecast.fit) method you can train a set of models to your dataset. You can modify the hyperparameters of the model to get a better accuracy, in this case we will use the default hyperparameters of `lgb.LGBMRegressor`. @@ -88,7 +88,7 @@ models = [lgb.LGBMRegressor(verbosity=-1)] ``` The -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object has the following parameters: - `models`: a list of sklearn-like (`fit` and `predict`) models. @@ -121,7 +121,7 @@ fcst.fit(Y_df_M3); Now we can transfer the trained model to forecast `AirPassengers` with the -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict) +[`MLForecast.predict`](forecast.html#mlforecast.predict) method, we just have to pass the new dataframe to the `new_data` argument. diff --git a/mlforecast/docs/how-to-guides/transforming_exog.html.mdx b/mlforecast/docs/how-to-guides/transforming_exog.html.mdx index 5552b5b8..39c17b4b 100644 --- a/mlforecast/docs/how-to-guides/transforming_exog.html.mdx +++ b/mlforecast/docs/how-to-guides/transforming_exog.html.mdx @@ -32,7 +32,7 @@ Suppose that you have some series along with their prices for each id and date and you want to compute forecasts for the next 7 days. Since the price is a dynamic feature you have to provide the future values through `X_df` in -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict). +[`MLForecast.predict`](forecast.html#mlforecast.predict). If you want to use not only the price but the lag7 of the price and the expanding mean of the lag1 for example, you can compute them before diff --git a/mlforecast/docs/tutorials/electricity_load_forecasting.html.mdx b/mlforecast/docs/tutorials/electricity_load_forecasting.html.mdx index 5dc00361..8a66eab0 100644 --- a/mlforecast/docs/tutorials/electricity_load_forecasting.html.mdx +++ b/mlforecast/docs/tutorials/electricity_load_forecasting.html.mdx @@ -136,12 +136,12 @@ from mlforecast.target_transforms import Differences ``` We can use the -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) method to explore different transformations. It looks like these series have a strong seasonality on the hour of the day, so we can subtract the value from the same hour in the previous day to remove it. This can be done with the -[`mlforecast.target_transforms.Differences`](https://Nixtla.github.io/mlforecast/target_transforms.html#differences) +[`mlforecast.target_transforms.Differences`](target_transforms.html#differences) transformer, which we pass through `target_transforms`. In order to analize the trends individually and combined we are going to @@ -205,7 +205,7 @@ all the differences `PJM_Load_hourly_all_diff`. For modeling we are going to use both difference for the forecasting, therefore we are setting the argument `target_transforms` from the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object equal to `[Differences([24, 24*7])]`, if we wanted to include a yearly difference we would need to add the term `24*365`. @@ -247,7 +247,7 @@ and try different combinations of them, alongside different target transformations (as the ones we created previously) and historical variables. You can see an in-depth tutorial on how to use -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) [Cross Validation methods here](https://nixtla.github.io/mlforecast/docs/cross_validation.html) @@ -266,7 +266,7 @@ from mlforecast.target_transforms import Differences We can create a benchmark `Naive` model that uses the electricity load of the last hour as prediction `lag1` as showed in the next cell. You can create your own models and try them with -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) using the same structure. ```python @@ -298,7 +298,7 @@ models ={ ``` The we can instanciate the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) class with the models we want to try along side `target_transforms`, `lags`, `lag_transforms`, and `date_features`. All this features are applied to the models we selected. @@ -454,7 +454,7 @@ the `naive`. Now we are going to evaluate their perfonce in the test set. We can use both of them for forecasting the test alongside some prediction intervals. For that we can use the -[\[`PredictionIntervals`\](https://Nixtla.github.io/mlforecast/utils.html#predictionintervals)](https://nixtla.github.io/mlforecast/utils.html#predictionintervals) +[\[`PredictionIntervals`\](utils.html#predictionintervals)](https://nixtla.github.io/mlforecast/utils.html#predictionintervals) function in `mlforecast.utils`. You can see an in-depth tutotorial of [Probabilistic Forecasting here](https://nixtla.github.io/mlforecast/docs/prediction_intervals.html) @@ -495,7 +495,7 @@ following arguments: - `target_col`: Column that contains the target. In our case, y. The -[`PredictionIntervals`](https://Nixtla.github.io/mlforecast/utils.html#predictionintervals) +[`PredictionIntervals`](utils.html#predictionintervals) function is used to compute prediction intervals for the models using [Conformal Prediction](https://valeman.medium.com/how-to-predict-full-probability-distribution-using-machine-learning-conformal-predictive-f8f4d805e420). @@ -595,7 +595,7 @@ One of the most widely used models for time series forecasting is `Prophet`. This model is known for its ability to model different seasonalities (weekly, daily yearly). We will use this model as a benchmark to see if the `lgbm` alongside -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) adds value for this time series. ```python @@ -729,7 +729,7 @@ lgbm with MLForecast has a speedup of 20.95 compared with prophet ``` We can see that `lgbm` with -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) was able to provide metrics at least twice as good as `Prophet` as seen in the column `improvement` above, and way faster. diff --git a/mlforecast/docs/tutorials/electricity_peak_forecasting.html.mdx b/mlforecast/docs/tutorials/electricity_peak_forecasting.html.mdx index 0ded3e23..c18a2ef5 100644 --- a/mlforecast/docs/tutorials/electricity_peak_forecasting.html.mdx +++ b/mlforecast/docs/tutorials/electricity_peak_forecasting.html.mdx @@ -32,7 +32,7 @@ the day such as 6:00pm vs 3:00am or for specific days such as Sunday vs Friday. First, we will load ERCOT historic demand, then we will use the -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation) +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation) method to fit the `LightGBM` model and forecast daily load during September. Finally, we show how to use the forecasts to detect the coincident peak. @@ -108,7 +108,7 @@ computationally efficient methods to deploy them in production. ## Fit and Forecast LightGBM model Import the -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) class and the models you need. ```python @@ -133,7 +133,7 @@ models = [ ``` We fit the model by instantiating a -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object with the following required parameters: - `models`: a list of sklearn-like (fit and predict) models. diff --git a/mlforecast/docs/tutorials/prediction_intervals_in_forecasting_models.html.mdx b/mlforecast/docs/tutorials/prediction_intervals_in_forecasting_models.html.mdx index 50b6b1ad..999c8ee1 100644 --- a/mlforecast/docs/tutorials/prediction_intervals_in_forecasting_models.html.mdx +++ b/mlforecast/docs/tutorials/prediction_intervals_in_forecasting_models.html.mdx @@ -10,10 +10,10 @@ on building `Prediction intervals in forecasting models` using During this walkthrough, we will become familiar with the main `MlForecast` class and some relevant methods such as -[`MLForecast.fit`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.fit), -[`MLForecast.predict`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.predict) +[`MLForecast.fit`](forecast.html#mlforecast.fit), +[`MLForecast.predict`](forecast.html#mlforecast.predict) and -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation) +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation) in other. Let’s start!!! @@ -666,7 +666,7 @@ model1 = [xgb.XGBRegressor()] ``` We can use the -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) method to explore different transformations. If it is true that the series we are working with is a stationary series @@ -674,7 +674,7 @@ see (Dickey fuller test), however for the sake of practice and instruction in this guide, we will apply the difference to our series, we will do this using the `target_transforms parameter` and calling the diff function like: -[`mlforecast.target_transforms.Differences`](https://Nixtla.github.io/mlforecast/target_transforms.html#differences) +[`mlforecast.target_transforms.Differences`](target_transforms.html#differences) ```python mlf = MLForecast(models=model1, diff --git a/mlforecast/forecast.html.mdx b/mlforecast/forecast.html.mdx index 9fd48631..7928207c 100644 --- a/mlforecast/forecast.html.mdx +++ b/mlforecast/forecast.html.mdx @@ -481,10 +481,10 @@ fig = plot_series(forecasts_df=results) #### Prediction intervals With -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast), +[`MLForecast`](forecast.html#mlforecast), you can generate prediction intervals using Conformal Prediction. To configure Conformal Prediction, you need to pass an instance of the -[`PredictionIntervals`](https://Nixtla.github.io/mlforecast/utils.html#predictionintervals) +[`PredictionIntervals`](utils.html#predictionintervals) class to the `prediction_intervals` argument of the `fit` method. The class takes three parameters: `n_windows`, `h` and `method`. @@ -535,7 +535,7 @@ fig = plot_series(forecasts_df=results, level=[50, 80, 95]) If you want to reduce the computational time and produce intervals with the same width for the whole forecast horizon, simple pass `h=1` to the -[`PredictionIntervals`](https://Nixtla.github.io/mlforecast/utils.html#predictionintervals) +[`PredictionIntervals`](utils.html#predictionintervals) class. The caveat of this strategy is that in some cases, variance of the absolute residuals maybe be small (even zero), so the intervals may be too narrow. @@ -660,7 +660,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source > ``` *Manually train models. Use this if you called -[`MLForecast.preprocess`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.preprocess) +[`MLForecast.preprocess`](forecast.html#mlforecast.preprocess) beforehand.* | | **Type** | **Details** | @@ -747,7 +747,7 @@ Since the data is time dependant we usually take the last *x* observations from our data as the validation set. This process is implemented in -[`MLForecast.cross_validation`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.cross_validation), +[`MLForecast.cross_validation`](forecast.html#mlforecast.cross_validation), which takes our data and performs the process described above for `n_windows` times where each window has `h` validation samples in it. For example, if we have 100 samples and we want to perform 2 backtests @@ -907,11 +907,11 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source Once you’ve found a set of features and parameters that work for your problem you can build a forecast object from it using -[`MLForecast.from_cv`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast.from_cv), +[`MLForecast.from_cv`](forecast.html#mlforecast.from_cv), which takes the trained -[`LightGBMCV`](https://Nixtla.github.io/mlforecast/lgb_cv.html#lightgbmcv) +[`LightGBMCV`](lgb_cv.html#lightgbmcv) object and builds an -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object that will use the same features and parameters. Then you can call fit and predict as you normally would. diff --git a/mlforecast/index.html.mdx b/mlforecast/index.html.mdx index a83a1106..bead4784 100644 --- a/mlforecast/index.html.mdx +++ b/mlforecast/index.html.mdx @@ -60,7 +60,7 @@ for best practices.** Current Python alternatives for machine learning models are slow, inaccurate and don’t scale well. So we created a library that can be used to forecast in production environments. -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) includes efficient feature engineering to train any machine learning model (with `fit` and `predict` methods such as [`sklearn`](https://scikit-learn.org/stable/)) to fit millions of time @@ -164,7 +164,7 @@ models = [ ### Forecast object Now instantiate an -[`MLForecast`](https://Nixtla.github.io/mlforecast/forecast.html#mlforecast) +[`MLForecast`](forecast.html#mlforecast) object with the models and the features that you want to use. The features can be lags, transformations on the lags and date features. You can also define transformations to apply to the target before fitting, diff --git a/nixtla/docs/capabilities/forecast/categorical_variables.html.mdx b/nixtla/docs/capabilities/forecast/categorical_variables.html.mdx index 625e36e1..ee076152 100644 --- a/nixtla/docs/capabilities/forecast/categorical_variables.html.mdx +++ b/nixtla/docs/capabilities/forecast/categorical_variables.html.mdx @@ -5,7 +5,7 @@ title: Add categorical variables TimeGPT supports categorical variables and we can create them using -[`SpecialDates`](https://Nixtla.github.io/nixtla/src/date_features.html#specialdates). +[`SpecialDates`](src/date_features.html#specialdates). [![](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/Nixtla/nixtla/blob/main/nbs/docs/capabilities/forecast/04_categorical_variables.ipynb) diff --git a/nixtla/docs/capabilities/online-anomaly-detection/adjusting_detection_process.html.mdx b/nixtla/docs/capabilities/online-anomaly-detection/adjusting_detection_process.html.mdx index d0af28c7..3b800ca2 100644 --- a/nixtla/docs/capabilities/online-anomaly-detection/adjusting_detection_process.html.mdx +++ b/nixtla/docs/capabilities/online-anomaly-detection/adjusting_detection_process.html.mdx @@ -49,7 +49,7 @@ nixtla_client = NixtlaClient( ## 1. Conduct anomaly detection After initializing an instance of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient), +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient), let’s explore an example using the Peyton Manning dataset. ```python diff --git a/nixtla/docs/getting-started/azure_quickstart.html.mdx b/nixtla/docs/getting-started/azure_quickstart.html.mdx index d38e013f..f5015db6 100644 --- a/nixtla/docs/getting-started/azure_quickstart.html.mdx +++ b/nixtla/docs/getting-started/azure_quickstart.html.mdx @@ -68,7 +68,7 @@ from nixtla import NixtlaClient ``` You can instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class providing your authentication API key. ```python diff --git a/nixtla/docs/getting-started/data_requirements.html.mdx b/nixtla/docs/getting-started/data_requirements.html.mdx index 6f365203..b800265c 100644 --- a/nixtla/docs/getting-started/data_requirements.html.mdx +++ b/nixtla/docs/getting-started/data_requirements.html.mdx @@ -49,11 +49,11 @@ Note that in this example, the `ds` column is named `timestamp` and the 2. Keep the current column names and specify them when using any method from the - [`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) + [`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class with the `time_col` and `target_col` arguments. For example, when using the `forecast` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, you must instantiate the class and then specify the columns names as follows. @@ -89,12 +89,12 @@ INFO:nixtla.nixtla_client:Calling Forecast Endpoint... | 4 | 1961-05-01 | 505.64648 | In this example, the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) is infereing the frequency, but you can explicitly specify it with the `freq` argument. To learn more about how to instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, refer to the [TimeGPT Quickstart](https://docs.nixtla.io/docs/getting-started-timegpt_quickstart) @@ -103,7 +103,7 @@ Quickstart](https://docs.nixtla.io/docs/getting-started-timegpt_quickstart) If you’re working with multiple time series, make sure that each series has a unique identifier. You can name this column `unique_id` or specify its name using the `id_col` argument when calling any method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. This column should be a string, integer, or category. In this example, we have five series representing hourly electricity diff --git a/nixtla/docs/getting-started/faq.html.mdx b/nixtla/docs/getting-started/faq.html.mdx index fa28258c..acea2d68 100644 --- a/nixtla/docs/getting-started/faq.html.mdx +++ b/nixtla/docs/getting-started/faq.html.mdx @@ -94,7 +94,7 @@ If you want to check the status of your API key, you can use the [`validate_api_key` method](https://nixtlaverse.nixtla.io/nixtla/nixtla_client.html#nixtlaclient-validate-api-key) of the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. `nixtla_client = NixtlaClient( api_key = 'my_api_key_provided_by_nixtla' )` @@ -114,7 +114,7 @@ What if my API key isn’t validating? When you validate your API key and it returns `False`: - If you are targeting an Azure endpoint, getting `False` from the - [`NixtlaClient.validate_api_key`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient.validate_api_key) + [`NixtlaClient.validate_api_key`](src/nixtla_client.html#nixtlaclient.validate_api_key) method is expected. You can skip this step when taregting an Azure endpoint and proceed diretly to forecasting instead. - If you are not taregting an Azure endpoint, then you should check @@ -251,7 +251,7 @@ tutorial. How can I plot the TimeGPT forecast? The -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class has a [`plot` method](https://nixtlaverse.nixtla.io/nixtla/nixtla_client.html#nixtlaclient-validate-token) that can be used to visualize the forecast. This method only works in @@ -298,7 +298,7 @@ model then produces the forecasts. You can control the number of training iterations and the loss function for fine-tuning with the `finetune_steps` and the `finetune_loss` parameters in the `forecast` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, respectively. For a comprehensive guide on how to apply fine-tuning, please refer to @@ -470,7 +470,7 @@ issue when working with large datasets. To fix this, consider increasing the `num_partitions` parameter in the [`forecast` method](https://nixtlaverse.nixtla.io/nixtla/nixtla_client.html#nixtlaclient-forecast) of the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, or use a distributed backend if not already in use. ## Additional Support diff --git a/nixtla/docs/getting-started/polars_quickstart.html.mdx b/nixtla/docs/getting-started/polars_quickstart.html.mdx index 70a127b7..85849eb4 100644 --- a/nixtla/docs/getting-started/polars_quickstart.html.mdx +++ b/nixtla/docs/getting-started/polars_quickstart.html.mdx @@ -38,7 +38,7 @@ from nixtla import NixtlaClient ``` You can instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class providing your authentication API key. ```python diff --git a/nixtla/docs/getting-started/quickstart.html.mdx b/nixtla/docs/getting-started/quickstart.html.mdx index 09c33c86..64f18b80 100644 --- a/nixtla/docs/getting-started/quickstart.html.mdx +++ b/nixtla/docs/getting-started/quickstart.html.mdx @@ -39,7 +39,7 @@ from nixtla import NixtlaClient ``` You can instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class providing your authentication API key. ```python diff --git a/nixtla/docs/getting-started/setting_up_your_api_key.html.mdx b/nixtla/docs/getting-started/setting_up_your_api_key.html.mdx index 44fbb73f..73acf73f 100644 --- a/nixtla/docs/getting-started/setting_up_your_api_key.html.mdx +++ b/nixtla/docs/getting-started/setting_up_your_api_key.html.mdx @@ -22,7 +22,7 @@ that won’t be shared. dashboard](https://dashboard.nixtla.io/). - **Step 2**: Paste the key directly into your Python code, by instantiating the - [`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) + [`NixtlaClient`](src/nixtla_client.html#nixtlaclient) with your API key: ```python @@ -41,7 +41,7 @@ nixtla_client = NixtlaClient(api_key ='your API key here') `NIXTLA_API_KEY`. This can be done (a) temporarily for a session or (b) permanently, depending on your preference. - **Step 2**: When you instantiate the - [`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) + [`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, the SDK will automatically look for the `NIXTLA_API_KEY` environment variable and use it to authenticate your requests. @@ -108,7 +108,7 @@ deployed or shared, as it keeps API keys out of the source code. You can always find your API key in the `API Keys` section of your dashboard. To check the status of your API key, use the `validate_api_key` method of the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. This method will return `True` if the API key is valid and `False` otherwise. diff --git a/nixtla/docs/tutorials/anomaly_detection.html.mdx b/nixtla/docs/tutorials/anomaly_detection.html.mdx index ac003e99..fe25013a 100644 --- a/nixtla/docs/tutorials/anomaly_detection.html.mdx +++ b/nixtla/docs/tutorials/anomaly_detection.html.mdx @@ -10,7 +10,7 @@ title: Anomaly detection First, we import the required packages for this tutorial and create an instance of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient). +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient). ```python import pandas as pd @@ -100,7 +100,7 @@ inside the confidence interval. A label of `True` is then assigned to abnormal points. We can also plot the anomalies using -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient). +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient). ```python nixtla_client.plot(df, anomalies_df) diff --git a/nixtla/docs/tutorials/computing_at_scale.html.mdx b/nixtla/docs/tutorials/computing_at_scale.html.mdx index 8ca34e87..d818f97d 100644 --- a/nixtla/docs/tutorials/computing_at_scale.html.mdx +++ b/nixtla/docs/tutorials/computing_at_scale.html.mdx @@ -47,7 +47,7 @@ frameworks is straightforward and its usage is almost identical to the non-distributed case. 1. Instantiate a - [`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) + [`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. 2. Load your data as a `pandas` DataFrame. 3. Initialize the distributed computing framework. @@ -55,7 +55,7 @@ non-distributed case. - [Dask](https://docs.nixtla.io/docs/tutorials-dask) - [Ray](https://docs.nixtla.io/docs/tutorials-ray) 4. Use any of the - [`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) + [`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class methods. 5. Stop the distributed computing framework, if necessary. diff --git a/nixtla/docs/tutorials/computing_at_scale_dask_distributed.html.mdx b/nixtla/docs/tutorials/computing_at_scale_dask_distributed.html.mdx index 8cd610f3..df5a4066 100644 --- a/nixtla/docs/tutorials/computing_at_scale_dask_distributed.html.mdx +++ b/nixtla/docs/tutorials/computing_at_scale_dask_distributed.html.mdx @@ -94,7 +94,7 @@ non-distributed case. The only difference is that you need to use a `Dask` DataFrame, which we already defined in the previous step. First, instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. ```python @@ -116,7 +116,7 @@ nixtla_client = NixtlaClient( > `nixtla_client = NixtlaClient(base_url="you azure ai endpoint", api_key="your api_key")` Then use any method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class such as [`forecast`](https://docs.nixtla.io/docs/reference-sdk_reference#nixtlaclientforecast) or diff --git a/nixtla/docs/tutorials/computing_at_scale_ray_distributed.html.mdx b/nixtla/docs/tutorials/computing_at_scale_ray_distributed.html.mdx index a8e84886..b3ddcf1c 100644 --- a/nixtla/docs/tutorials/computing_at_scale_ray_distributed.html.mdx +++ b/nixtla/docs/tutorials/computing_at_scale_ray_distributed.html.mdx @@ -107,7 +107,7 @@ non-distributed case. The only difference is that you need to use a `Ray` DataFrame. First, instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. ```python @@ -129,7 +129,7 @@ nixtla_client = NixtlaClient( > `nixtla_client = NixtlaClient(base_url="you azure ai endpoint", api_key="your api_key")` Then use any method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class such as [`forecast`](https://docs.nixtla.io/docs/reference-sdk_reference#nixtlaclientforecast) or diff --git a/nixtla/docs/tutorials/computing_at_scale_spark_distributed.html.mdx b/nixtla/docs/tutorials/computing_at_scale_spark_distributed.html.mdx index d84dcfbe..7880b44e 100644 --- a/nixtla/docs/tutorials/computing_at_scale_spark_distributed.html.mdx +++ b/nixtla/docs/tutorials/computing_at_scale_spark_distributed.html.mdx @@ -95,7 +95,7 @@ non-distributed case. The only difference is that you need to use a `Spark` DataFrame. First, instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. ```python @@ -117,7 +117,7 @@ nixtla_client = NixtlaClient( > `nixtla_client = NixtlaClient(base_url="you azure ai endpoint", api_key="your api_key")` Then use any method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class such as [`forecast`](https://docs.nixtla.io/docs/reference-sdk_reference#nixtlaclientforecast) or diff --git a/nixtla/docs/tutorials/cross_validation.html.mdx b/nixtla/docs/tutorials/cross_validation.html.mdx index 8341ac3d..a07baf04 100644 --- a/nixtla/docs/tutorials/cross_validation.html.mdx +++ b/nixtla/docs/tutorials/cross_validation.html.mdx @@ -19,7 +19,7 @@ practitioners to rigorously test their forecasting models against historical data, assessing their effectiveness while tuning them for optimal performance. This tutorial will guide you through the nuanced process of conducting cross-validation within the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, ensuring your time series forecasting models are not just well-constructed, but also validated for trustworthiness and precision. @@ -31,7 +31,7 @@ First, we install and import the required packages and initialize the Nixtla client. We start off by initializing an instance of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient). +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient). ```python import pandas as pd diff --git a/nixtla/docs/tutorials/missing_values.html.mdx b/nixtla/docs/tutorials/missing_values.html.mdx index 6f49fc80..c36bfc95 100644 --- a/nixtla/docs/tutorials/missing_values.html.mdx +++ b/nixtla/docs/tutorials/missing_values.html.mdx @@ -94,7 +94,7 @@ train_df_gaps = train_df[mask] ## Get Started with TimeGPT Before proceeding, we will instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class, which provides access to all the methods from `TimeGPT`. To do this, you will need a Nixtla API key. @@ -124,7 +124,7 @@ tutorial. ## Visualize Data We can visualize the data using the `plot` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. This method has an `engine` argument that allows you to choose between different plotting libraries. Default is `matplotlib`, but you can also use `plotly` for interactive plots. @@ -255,7 +255,7 @@ dtype: int64 ## Forecast with TimeGPT We are now ready to use the `forecast` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. This method requires the following arguments: - `df`: The DataFrame containing the time series data diff --git a/nixtla/docs/tutorials/multiple_series.html.mdx b/nixtla/docs/tutorials/multiple_series.html.mdx index 44ad36bb..b0238568 100644 --- a/nixtla/docs/tutorials/multiple_series.html.mdx +++ b/nixtla/docs/tutorials/multiple_series.html.mdx @@ -27,7 +27,7 @@ First, we install and import the required packages and initialize the Nixtla client. As always, we start off by intializing an instance of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient). +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient). ```python import pandas as pd @@ -76,7 +76,7 @@ df.head() | 4 | BE | 2016-12-01 04:00:00 | 52.58 | Let’s plot this series using -[\[`NixtlaClient`\](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient)](https://nixtlaverse.nixtla.io/nixtla/nixtla_client.html#nixtlaclient): +[\[`NixtlaClient`\](src/nixtla_client.html#nixtlaclient)](https://nixtlaverse.nixtla.io/nixtla/nixtla_client.html#nixtlaclient): ```python nixtla_client.plot(df) diff --git a/nixtla/docs/tutorials/reusing_finetuned_models.html.mdx b/nixtla/docs/tutorials/reusing_finetuned_models.html.mdx index 6af31938..754b24a7 100644 --- a/nixtla/docs/tutorials/reusing_finetuned_models.html.mdx +++ b/nixtla/docs/tutorials/reusing_finetuned_models.html.mdx @@ -116,7 +116,7 @@ We can see the error was reduced. ## 5. Further fine-tune We can now take this model and fine-tune it a bit further by using the -[`NixtlaClient.finetune`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient.finetune) +[`NixtlaClient.finetune`](src/nixtla_client.html#nixtlaclient.finetune) method but providing our already fine-tuned model as `finetuned_model_id`, which will take that model and fine-tune it a bit more. We can also change the fine-tuning settings, like using @@ -165,7 +165,7 @@ We can see the error was reduced a bit more. ## 6. Listing fine-tuned models We can list our fine-tuned models with the -[`NixtlaClient.finetuned_models`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient.finetuned_models) +[`NixtlaClient.finetuned_models`](src/nixtla_client.html#nixtlaclient.finetuned_models) method. ```python diff --git a/nixtla/docs/use-cases/bitcoin_price_prediction.html.mdx b/nixtla/docs/use-cases/bitcoin_price_prediction.html.mdx index 25e4456d..347ba363 100644 --- a/nixtla/docs/use-cases/bitcoin_price_prediction.html.mdx +++ b/nixtla/docs/use-cases/bitcoin_price_prediction.html.mdx @@ -87,7 +87,7 @@ df.rename(columns={'Date': 'ds', 'Close': 'y'}, inplace=True) ## 2. Get Started with TimeGPT To get started with `TimeGPT`, you need to instantiate the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. For this, you will need a Nixtla API key. ```python @@ -118,7 +118,7 @@ tutorial. Before attempting any forecasting, it is good practice to visualize the data we want to predict. The -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class includes a `plot` method for this purpose. The `plot` method has an `engine` argument that allows you to choose @@ -141,14 +141,14 @@ nixtla_client.plot(df, time_col='name of your time column', target_col='name of This is necessary not only for the `plot` method but for all methods from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. ## 4. Forecast with TimeGPT Now we are ready to generate predictions with TimeGPT. To do this, we will use the `forecast` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. The `forecast` method requires the following arguments: @@ -273,7 +273,7 @@ nixtla_client.plot(df, forecast, level=level) Given the volatility of the price of Bitcoin, it can be useful to try to identify anomalies in the data. `TimeGPT` can be used for this by calling the `detect_anomalies` method from the -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) class. This method evaluates each observation against its context within the series, using statistical measures to determine its likelihood of being an anomaly. By default, it identifies anomalies based on a 99 diff --git a/nixtla/docs/use-cases/electricity_demand.html.mdx b/nixtla/docs/use-cases/electricity_demand.html.mdx index d5f2e182..65e7f703 100644 --- a/nixtla/docs/use-cases/electricity_demand.html.mdx +++ b/nixtla/docs/use-cases/electricity_demand.html.mdx @@ -44,7 +44,7 @@ from utilsforecast.evaluation import evaluate ``` Of course, we need an instance of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient) +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient) to use TimeGPT. ```python diff --git a/nixtla/docs/use-cases/intermittent_demand.html.mdx b/nixtla/docs/use-cases/intermittent_demand.html.mdx index b0a0435d..3c4bc46a 100644 --- a/nixtla/docs/use-cases/intermittent_demand.html.mdx +++ b/nixtla/docs/use-cases/intermittent_demand.html.mdx @@ -25,7 +25,7 @@ better predictions with TimeGPT. We start off by importing the required packages for this tutorial and create an instace of -[`NixtlaClient`](https://Nixtla.github.io/nixtla/src/nixtla_client.html#nixtlaclient). +[`NixtlaClient`](src/nixtla_client.html#nixtlaclient). ```python import time diff --git a/statsforecast/docs/experiments/amazonstatsforecast.html.mdx b/statsforecast/docs/experiments/amazonstatsforecast.html.mdx index 8e9da2d0..9fc8b793 100644 --- a/statsforecast/docs/experiments/amazonstatsforecast.html.mdx +++ b/statsforecast/docs/experiments/amazonstatsforecast.html.mdx @@ -139,15 +139,15 @@ Y_df_m5.head() ### Train statistical models We fit the model by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following parameters: - `models`: a list of models. Select the models you want from [models](../models.html) and import them. For this example, we will use - [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets) + [`AutoETS`](src/core/models.html#autoets) and - [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta). + [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta). We set `season_length` to 7 because we expect seasonal effects every week. (See: [Seasonal periods](https://robjhyndman.com/hyndsight/seasonal-periods/)) @@ -171,21 +171,21 @@ method and pass in the historical data frame. > should take around 5 seconds. The second time -once Numba compiled > your settings- it should take less than 0.2s. -- [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets): +- [`AutoETS`](src/core/models.html#autoets): Exponential Smoothing model. Automatically selects the best ETS (Error, Trend, Seasonality) model using an information criterion. Ref: - [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets). + [`AutoETS`](src/core/models.html#autoets). -- [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive): +- [`SeasonalNaive`](src/core/models.html#seasonalnaive): Memory Efficient Seasonal Naive predictions. Ref: - [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive). + [`SeasonalNaive`](src/core/models.html#seasonalnaive). -- [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta): +- [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta): fit two theta lines to a deseasonalized time series, using different techniques to obtain and combine the two theta lines to produce the final forecasts. Ref: - [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta). + [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta). ```python @@ -268,7 +268,7 @@ forecasts_df.to_parquet('s3://m5-benchmarks/forecasts/statsforecast-m5.parquet') ## Evaluation This section evaluates the performance of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) and `AmazonForecast`. To do this, we first need to install [datasetsforecast](https://github.com/Nixtla/datasetsforecast), a Python library developed by Nixtla that includes a large battery of benchmark diff --git a/statsforecast/docs/experiments/autoarima_vs_prophet.html.mdx b/statsforecast/docs/experiments/autoarima_vs_prophet.html.mdx index ba49fbbf..e15b1369 100644 --- a/statsforecast/docs/experiments/autoarima_vs_prophet.html.mdx +++ b/statsforecast/docs/experiments/autoarima_vs_prophet.html.mdx @@ -9,15 +9,15 @@ title: AutoARIMA Comparison (Prophet and pmdarima) ## Motivation The -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model is widely used to forecast time series in production and as a benchmark. However, the python implementation (`pmdarima`) is so slow that prevent data scientist practioners from quickly iterating and deploying -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) in production for a large number of time series. In this notebook we present Nixtla’s -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) based on the R implementation (developed by Rob Hyndman) and optimized using `numba`. @@ -123,7 +123,7 @@ data. ### Training and forecasting -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) receives a list of models to fit each time series. Since we are dealing with Hourly data, it would be benefitial to use 24 as seasonality. @@ -257,7 +257,7 @@ Subclasses: ``` As we see, we can pass `season_length` to -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima), +[`AutoARIMA`](src/core/models.html#autoarima), so the definition of our models would be, @@ -323,7 +323,7 @@ plot_series(train, test) ### pmdarima You can use the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class to parallelize your own models. In this section we will use it to run the `auto_arima` model from `pmdarima`. @@ -532,7 +532,7 @@ plot_series(train, test) ### Time Since -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) works with numba is useful to calculate the time for just one time series. diff --git a/statsforecast/docs/experiments/ets_ray_m5.html.mdx b/statsforecast/docs/experiments/ets_ray_m5.html.mdx index 5f08e4a1..1c472237 100644 --- a/statsforecast/docs/experiments/ets_ray_m5.html.mdx +++ b/statsforecast/docs/experiments/ets_ray_m5.html.mdx @@ -6,10 +6,10 @@ title: Forecasting at Scale using ETS and ray (M5) In this notebook we show how to use -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) and `ray` to forecast thounsands of time series in less than 6 minutes (M5 dataset). Also, we show that -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) has better performance in time and accuracy compared to [`Prophet` running on a Spark cluster](http:nixtla.github.io/statsforecast/examples/Prophet_spark_m5.html) @@ -77,7 +77,7 @@ Y_df['y'] += constant ## Train the model -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) receives a list of models to fit each time series. Since we are dealing with Daily data, it would be benefitial to use 7 as seasonality. Observe that we need to pass the ray address to the `ray_address` argument. @@ -110,7 +110,7 @@ print(f'Minutes taken by StatsForecast using: {(end - init) / 60}') Minutes taken by StatsForecast using: 5.4817593971888225 ``` -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) and `ray` took only 5.48 minutes to train `30,490` time series, compared to 18.23 minutes for Prophet and Spark. @@ -165,7 +165,7 @@ M5Evaluation.evaluate(y_hat=Y_hat, directory='./data') | Level12 | 0.916175 | Also, -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) is more accurate than Prophet, since the overall WMRSSE is `0.68`, against `0.77` obtained by prophet. diff --git a/statsforecast/docs/getting-started/getting_started_complete.html.mdx b/statsforecast/docs/getting-started/getting_started_complete.html.mdx index d2a98111..a73f9566 100644 --- a/statsforecast/docs/getting-started/getting_started_complete.html.mdx +++ b/statsforecast/docs/getting-started/getting_started_complete.html.mdx @@ -14,9 +14,9 @@ Follow this article for a step to step guide on building a production-ready forecasting pipeline for multiple time series. During this guide you will gain familiary with the core -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast)class +[`StatsForecast`](src/core/core.html#statsforecast)class and some relevant methods like `StatsForecast.plot`, -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) and `StatsForecast.cross_validation.` We will use a classical benchmarking dataset from the M4 competition. @@ -132,7 +132,7 @@ Y_df = Y_df.groupby('unique_id').tail(7 * 24) #Select last 7 days of data to mak ## Explore Data with the plot method Plot some series using the `plot` method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class. This method prints 8 random series from the dataset and is useful for basic EDA. @@ -190,29 +190,29 @@ Here you can check the complete list of For this example we will use: -- [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima): +- [`AutoARIMA`](src/core/models.html#autoarima): Automatically selects the best ARIMA (AutoRegressive Integrated Moving Average) model using an information criterion. Ref: - [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima). + [`AutoARIMA`](src/core/models.html#autoarima). -- [`HoltWinters`](https://Nixtla.github.io/statsforecast/src/core/models.html#holtwinters): +- [`HoltWinters`](src/core/models.html#holtwinters): triple exponential smoothing, Holt-Winters’ method is an extension of exponential smoothing for series that contain both trend and seasonality. Ref: - [`HoltWinters`](https://Nixtla.github.io/statsforecast/src/core/models.html#holtwinters) + [`HoltWinters`](src/core/models.html#holtwinters) -- [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive): +- [`SeasonalNaive`](src/core/models.html#seasonalnaive): Memory Efficient Seasonal Naive predictions. Ref: - [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) + [`SeasonalNaive`](src/core/models.html#seasonalnaive) -- [`HistoricAverage`](https://Nixtla.github.io/statsforecast/src/core/models.html#historicaverage): +- [`HistoricAverage`](src/core/models.html#historicaverage): arthimetic mean. Ref: - [`HistoricAverage`](https://Nixtla.github.io/statsforecast/src/core/models.html#historicaverage). + [`HistoricAverage`](src/core/models.html#historicaverage). -- [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta): +- [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta): The theta family of models has been shown to perform well in various datasets such as M3. Models the deseasonalized time series. Ref: - [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta). + [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta). Import and instantiate the models. Setting the `season_length` argument is sometimes tricky. This article on [Seasonal @@ -243,7 +243,7 @@ models = [ ``` We fit the models by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following parameters: - `models`: a list of models. Select the models you want from @@ -383,9 +383,9 @@ Depending on your computer, this step should take around 1 min. > serving as the testing set. The -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class takes the following arguments. - `df`: training data frame diff --git a/statsforecast/docs/getting-started/getting_started_complete_polars.html.mdx b/statsforecast/docs/getting-started/getting_started_complete_polars.html.mdx index ebc4b7a8..e1d3feee 100644 --- a/statsforecast/docs/getting-started/getting_started_complete_polars.html.mdx +++ b/statsforecast/docs/getting-started/getting_started_complete_polars.html.mdx @@ -45,9 +45,9 @@ Follow this article for a step to step guide on building a production-ready forecasting pipeline for multiple time series. During this guide you will gain familiary with the core -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast)class +[`StatsForecast`](src/core/core.html#statsforecast)class and some relevant methods like `StatsForecast.plot`, -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) and `StatsForecast.cross_validation.` We will use a classical benchmarking dataset from the M4 competition. @@ -162,7 +162,7 @@ Y_df = Y_df.group_by('unique_id').tail(7 * 24) #Select last 7 days of data to ma ## Explore Data with the plot method Plot some series using the `plot` method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class. This method prints 8 random series from the dataset and is useful for basic EDA. @@ -219,29 +219,29 @@ Here you can check the complete list of [models](../models_intro.qmd). For this example we will use: -- [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima): +- [`AutoARIMA`](src/core/models.html#autoarima): Automatically selects the best ARIMA (AutoRegressive Integrated Moving Average) model using an information criterion. Ref: - [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima). + [`AutoARIMA`](src/core/models.html#autoarima). -- [`HoltWinters`](https://Nixtla.github.io/statsforecast/src/core/models.html#holtwinters): +- [`HoltWinters`](src/core/models.html#holtwinters): triple exponential smoothing, Holt-Winters’ method is an extension of exponential smoothing for series that contain both trend and seasonality. Ref: - [`HoltWinters`](https://Nixtla.github.io/statsforecast/src/core/models.html#holtwinters) + [`HoltWinters`](src/core/models.html#holtwinters) -- [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive): +- [`SeasonalNaive`](src/core/models.html#seasonalnaive): Memory Efficient Seasonal Naive predictions. Ref: - [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) + [`SeasonalNaive`](src/core/models.html#seasonalnaive) -- [`HistoricAverage`](https://Nixtla.github.io/statsforecast/src/core/models.html#historicaverage): +- [`HistoricAverage`](src/core/models.html#historicaverage): arthimetic mean. Ref: - [`HistoricAverage`](https://Nixtla.github.io/statsforecast/src/core/models.html#historicaverage). + [`HistoricAverage`](src/core/models.html#historicaverage). -- [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta): +- [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta): The theta family of models has been shown to perform well in various datasets such as M3. Models the deseasonalized time series. Ref: - [`DynamicOptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#dynamicoptimizedtheta). + [`DynamicOptimizedTheta`](src/core/models.html#dynamicoptimizedtheta). Import and instantiate the models. Setting the `season_length` argument is sometimes tricky. This article on [Seasonal @@ -272,7 +272,7 @@ models = [ ``` We fit the models by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following parameters: - `models`: a list of models. Select the models you want from @@ -419,9 +419,9 @@ Depending on your computer, this step should take around 1 min. > serving as the testing set. The -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class takes the following arguments. - `df`: training data frame diff --git a/statsforecast/docs/getting-started/getting_started_short.html.mdx b/statsforecast/docs/getting-started/getting_started_short.html.mdx index eb494359..f3dcf168 100644 --- a/statsforecast/docs/getting-started/getting_started_short.html.mdx +++ b/statsforecast/docs/getting-started/getting_started_short.html.mdx @@ -5,7 +5,7 @@ title: Quick Start --- -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) follows the sklearn model API. For this minimal example, you will create an instance of the StatsForecast class and then call its `fit` and `predict` methods. We recommend this option if speed is not paramount @@ -66,13 +66,13 @@ df.head() | 4 | AirPassengers | 1949-05-01 | 121 | We fit the model by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with its two required parameters: https://nixtla.github.io/statsforecast/src/core/models.html \* `models`: a list of models. Select the models you want from [models](../../src/core/models.html) and import them. For this example, we will use a -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model. We set `season_length` to 12 because we expect seasonal effects every 12 months. (See: [Seasonal periods](https://robjhyndman.com/hyndsight/seasonal-periods/)) diff --git a/statsforecast/docs/getting-started/installation.html.mdx b/statsforecast/docs/getting-started/installation.html.mdx index 113f8817..d21a2f5f 100644 --- a/statsforecast/docs/getting-started/installation.html.mdx +++ b/statsforecast/docs/getting-started/installation.html.mdx @@ -6,7 +6,7 @@ title: Install You can install the *released version* of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) from the [Python package index](https://pypi.org) with: diff --git a/statsforecast/docs/how-to-guides/generating_features.html.mdx b/statsforecast/docs/how-to-guides/generating_features.html.mdx index b72419e7..eb8d2253 100644 --- a/statsforecast/docs/how-to-guides/generating_features.html.mdx +++ b/statsforecast/docs/how-to-guides/generating_features.html.mdx @@ -7,10 +7,10 @@ title: Generating features Some models create internal representations of the series that can be useful for other models to use as inputs. One example is the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model, which decomposes the series into trend and seasonal components. This guide shows you how to use the -[`mstl_decomposition`](https://Nixtla.github.io/statsforecast/src/feature_engineering.html#mstl_decomposition) +[`mstl_decomposition`](src/feature_engineering.html#mstl_decomposition) function to extract those features for training and then use their future values for inference. diff --git a/statsforecast/docs/how-to-guides/sklearn_models.html.mdx b/statsforecast/docs/how-to-guides/sklearn_models.html.mdx index 1199429e..c282d04c 100644 --- a/statsforecast/docs/how-to-guides/sklearn_models.html.mdx +++ b/statsforecast/docs/how-to-guides/sklearn_models.html.mdx @@ -6,7 +6,7 @@ title: Sklearn models statsforecast supports providing scikit-learn models through the -[`statsforecast.models.SklearnModel`](https://Nixtla.github.io/statsforecast/src/core/models.html#sklearnmodel) +[`statsforecast.models.SklearnModel`](src/core/models.html#sklearnmodel) wrapper. This can help you leverage feature engineering and train one model per serie, which can sometimes be better than training a single global model (as in mlforecast). diff --git a/statsforecast/docs/models/adida.html.mdx b/statsforecast/docs/models/adida.html.mdx index 473f32eb..56b4b466 100644 --- a/statsforecast/docs/models/adida.html.mdx +++ b/statsforecast/docs/models/adida.html.mdx @@ -506,7 +506,7 @@ models = [ADIDA()] ``` We fit the models by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following parameters: models: a list of models. Select the models you want from models and @@ -561,7 +561,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `forecast()` method does not store the diff --git a/statsforecast/docs/models/arch.html.mdx b/statsforecast/docs/models/arch.html.mdx index 796da7a2..8a05f920 100644 --- a/statsforecast/docs/models/arch.html.mdx +++ b/statsforecast/docs/models/arch.html.mdx @@ -26,7 +26,7 @@ these facts, new models different from the Box- Jenkins ones are needed. And for this reason, ARCH models were firstly proposed by R. F. Engle in 1982 and have been extended by a great number of scholars since then. We also demonstrate how to use Python and its libraries to implement -[`ARCH`](https://Nixtla.github.io/statsforecast/src/core/models.html#arch). +[`ARCH`](src/core/models.html#arch). As we have known, there are lot of time series that possess the ARCH effect, that is, although the (modeling residual) series is white noise, @@ -602,7 +602,7 @@ ljung_res.head() Let’s divide our data into sets 1. Data to train our - [`ARCH`](https://Nixtla.github.io/statsforecast/src/core/models.html#arch) + [`ARCH`](src/core/models.html#arch) model 2. Data to test our model @@ -794,7 +794,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/autoarima.html.mdx b/statsforecast/docs/models/autoarima.html.mdx index 93a59abc..78be1d9b 100644 --- a/statsforecast/docs/models/autoarima.html.mdx +++ b/statsforecast/docs/models/autoarima.html.mdx @@ -39,7 +39,7 @@ the parameter selection process and can provide a fast and effective solution for time series modeling and forecasting. The `statsforecast.models` library brings the -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) function from Python provides an implementation of autoARIMA that allows to automatically select the optimal parameters for an ARIMA model given a time series. @@ -468,7 +468,7 @@ StatsForecast(models=[AutoARIMA]) ``` Once we have entered our model, we can use the -[`arima_string`](https://Nixtla.github.io/statsforecast/src/arima.html#arima_string) +[`arima_string`](src/arima.html#arima_string) function to see the parameters that the model has found. @@ -561,7 +561,7 @@ In this case we will only calculate the 90% forecast interval If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -584,9 +584,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/autoces.html.mdx b/statsforecast/docs/models/autoces.html.mdx index b198d047..fe5237fe 100644 --- a/statsforecast/docs/models/autoces.html.mdx +++ b/statsforecast/docs/models/autoces.html.mdx @@ -760,7 +760,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -783,9 +783,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/autoregressive.html.mdx b/statsforecast/docs/models/autoregressive.html.mdx index 3461e8fc..83c62805 100644 --- a/statsforecast/docs/models/autoregressive.html.mdx +++ b/statsforecast/docs/models/autoregressive.html.mdx @@ -689,7 +689,7 @@ the AR model. ## Split the data into training and testing Let’s divide our data into sets 1. Data to train our -[`AutoRegressive`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoregressive) +[`AutoRegressive`](src/core/models.html#autoregressive) model 2. Data to test our model For the test data we will use the last 12 months to test and evaluate @@ -860,7 +860,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -883,9 +883,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/autotheta.html.mdx b/statsforecast/docs/models/autotheta.html.mdx index ffcb9595..eb3bc648 100644 --- a/statsforecast/docs/models/autotheta.html.mdx +++ b/statsforecast/docs/models/autotheta.html.mdx @@ -19,13 +19,13 @@ title: AutoTheta Model ## Introduction The -[`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta) +[`AutoTheta`](src/core/models.html#autotheta) model in -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) automatically selects the best **Theta model** based on the **mean squared error (MSE)**. In this section, we will discuss each of the models that -[`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta) +[`AutoTheta`](src/core/models.html#autotheta) considers and then explain how it selects the best one. ### 1. Standard Theta Model (STM) @@ -62,7 +62,7 @@ the model dynamically with new data. ## How AutoTheta Selects the Best Model -1. [`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta) +1. [`AutoTheta`](src/core/models.html#autotheta) fits all four variants of the Theta model (STM, OTM, DSTM, and DOTM) to your data. 2. Each model is evaluated using cross-validation or a hold-out @@ -216,7 +216,7 @@ plt.show(); ## Split the data into training and testing Let’s divide our data into sets 1. Data to train our -[`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta) +[`AutoTheta`](src/core/models.html#autotheta) model 2. Data to test our model For the test data we will use the last 12 months to test and evaluate @@ -674,7 +674,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -697,9 +697,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/crostonclassic.html.mdx b/statsforecast/docs/models/crostonclassic.html.mdx index 44e7ef90..c76d5019 100644 --- a/statsforecast/docs/models/crostonclassic.html.mdx +++ b/statsforecast/docs/models/crostonclassic.html.mdx @@ -624,7 +624,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/crostonoptimized.html.mdx b/statsforecast/docs/models/crostonoptimized.html.mdx index da3e7466..78a962c1 100644 --- a/statsforecast/docs/models/crostonoptimized.html.mdx +++ b/statsforecast/docs/models/crostonoptimized.html.mdx @@ -519,7 +519,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/crostonsba.html.mdx b/statsforecast/docs/models/crostonsba.html.mdx index 3dd72b8c..17ee70ac 100644 --- a/statsforecast/docs/models/crostonsba.html.mdx +++ b/statsforecast/docs/models/crostonsba.html.mdx @@ -504,7 +504,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -521,9 +521,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/dynamicoptimizedtheta.html.mdx b/statsforecast/docs/models/dynamicoptimizedtheta.html.mdx index bb33a8a3..1e16e0e1 100644 --- a/statsforecast/docs/models/dynamicoptimizedtheta.html.mdx +++ b/statsforecast/docs/models/dynamicoptimizedtheta.html.mdx @@ -23,7 +23,7 @@ title: Dynamic Optimized Theta Model ## Introduction The **Dynamic Optimized Theta Model (DOTM)** in -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) is a variation of the classic Theta model. It combines key features of two other extensions: the **Optimized Theta Model (OTM)** and the **Dynamic Standard Theta Model (DSTM)**. @@ -430,7 +430,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/dynamicstandardtheta.html.mdx b/statsforecast/docs/models/dynamicstandardtheta.html.mdx index 6994d943..874ee597 100644 --- a/statsforecast/docs/models/dynamicstandardtheta.html.mdx +++ b/statsforecast/docs/models/dynamicstandardtheta.html.mdx @@ -400,7 +400,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/garch.html.mdx b/statsforecast/docs/models/garch.html.mdx index 5f4d19b0..86df35d8 100644 --- a/statsforecast/docs/models/garch.html.mdx +++ b/statsforecast/docs/models/garch.html.mdx @@ -63,7 +63,7 @@ $\text{ARCH}(p)$ model defined by (1) will provide an adequate fit only if the order $p$ is large. By allowing past volatilities to affect the present volatility in (1), a more parsimonious model may result. That is why we need -[`GARCH`](https://Nixtla.github.io/statsforecast/src/core/models.html#garch) +[`GARCH`](src/core/models.html#garch) models. Besides, note the condition that the order $p ≥ 1$. The **GARCH model** in Definition 1 has the properties as follows. @@ -555,7 +555,7 @@ ljung_res.head() ## Split the data into training and testing Let’s divide our data into sets 1. Data to train our -[`GARCH`](https://Nixtla.github.io/statsforecast/src/core/models.html#garch) +[`GARCH`](src/core/models.html#garch) model 2. Data to test our model For the test data we will use the last 30 day to test and evaluate the @@ -743,7 +743,7 @@ evals.drop(columns='metric').loc[0].idxmin() to train and test the model, and the models you want to test. This is an example, where the objective is to be able to teach a methodology for the use of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast), +[`StatsForecast`](src/core/core.html#statsforecast), and in particular the GARCH model and the parameters used in Cross Validation to determine the best model for this example. @@ -856,7 +856,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -879,9 +879,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/holt.html.mdx b/statsforecast/docs/models/holt.html.mdx index 2138ec9c..62475b39 100644 --- a/statsforecast/docs/models/holt.html.mdx +++ b/statsforecast/docs/models/holt.html.mdx @@ -864,7 +864,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/holtwinters.html.mdx b/statsforecast/docs/models/holtwinters.html.mdx index 47804aaa..11e9deff 100644 --- a/statsforecast/docs/models/holtwinters.html.mdx +++ b/statsforecast/docs/models/holtwinters.html.mdx @@ -757,7 +757,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/imapa.html.mdx b/statsforecast/docs/models/imapa.html.mdx index 8ba20338..b58bc0fc 100644 --- a/statsforecast/docs/models/imapa.html.mdx +++ b/statsforecast/docs/models/imapa.html.mdx @@ -465,7 +465,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/multipleseasonaltrend.html.mdx b/statsforecast/docs/models/multipleseasonaltrend.html.mdx index aaa39009..104edaa8 100644 --- a/statsforecast/docs/models/multipleseasonaltrend.html.mdx +++ b/statsforecast/docs/models/multipleseasonaltrend.html.mdx @@ -564,12 +564,12 @@ First, we must define the model parameters. As mentioned before, the Candy production load presents seasonalities every 24 hours (Hourly) and every 24 \* 7 (Daily) hours. Therefore, we will use `[24, 24 * 7]` for season length. The trend component will be forecasted with an -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model. (You can also try with: -[`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta), -[`AutoCES`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoces), +[`AutoTheta`](src/core/models.html#autotheta), +[`AutoCES`](src/core/models.html#autoces), and -[`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets)) +[`AutoETS`](src/core/models.html#autoets)) ```python @@ -646,7 +646,7 @@ plt.show() If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -669,9 +669,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/optimizedtheta.html.mdx b/statsforecast/docs/models/optimizedtheta.html.mdx index af2af829..7d1d6c33 100644 --- a/statsforecast/docs/models/optimizedtheta.html.mdx +++ b/statsforecast/docs/models/optimizedtheta.html.mdx @@ -608,7 +608,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted @@ -631,9 +631,9 @@ the name of the model and the y hat values, as well as columns for the uncertainty intervals. Depending on your computer, this step should take around 1min. (If you want to speed things up to a couple of seconds, remove the AutoModels like -[`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima) +[`ARIMA`](src/core/models.html#arima) and -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta)) +[`Theta`](src/core/models.html#theta)) ```python diff --git a/statsforecast/docs/models/seasonalexponentialsmoothing.html.mdx b/statsforecast/docs/models/seasonalexponentialsmoothing.html.mdx index 7e1ce059..271332b8 100644 --- a/statsforecast/docs/models/seasonalexponentialsmoothing.html.mdx +++ b/statsforecast/docs/models/seasonalexponentialsmoothing.html.mdx @@ -673,7 +673,7 @@ plt.show() If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/seasonalexponentialsmoothingoptimized.html.mdx b/statsforecast/docs/models/seasonalexponentialsmoothingoptimized.html.mdx index a6a6eebe..8000e4e9 100644 --- a/statsforecast/docs/models/seasonalexponentialsmoothingoptimized.html.mdx +++ b/statsforecast/docs/models/seasonalexponentialsmoothingoptimized.html.mdx @@ -611,7 +611,7 @@ plt.show() If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/simpleexponentialoptimized.html.mdx b/statsforecast/docs/models/simpleexponentialoptimized.html.mdx index 8759efe7..78aff82f 100644 --- a/statsforecast/docs/models/simpleexponentialoptimized.html.mdx +++ b/statsforecast/docs/models/simpleexponentialoptimized.html.mdx @@ -419,7 +419,7 @@ plt.show() If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/simpleexponentialsmoothing.html.mdx b/statsforecast/docs/models/simpleexponentialsmoothing.html.mdx index 9ee1cdac..98e379bb 100644 --- a/statsforecast/docs/models/simpleexponentialsmoothing.html.mdx +++ b/statsforecast/docs/models/simpleexponentialsmoothing.html.mdx @@ -477,7 +477,7 @@ plt.show() If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/standardtheta.html.mdx b/statsforecast/docs/models/standardtheta.html.mdx index 2141bcb7..bec1e44c 100644 --- a/statsforecast/docs/models/standardtheta.html.mdx +++ b/statsforecast/docs/models/standardtheta.html.mdx @@ -399,7 +399,7 @@ a.plot(); ## Split the data into training and testing Let’s divide our data into sets 1. Data to train our -[`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta) +[`Theta`](src/core/models.html#theta) model 2. Data to test our model For the test data we will use the last 12 months to test and evaluate @@ -547,7 +547,7 @@ plt.show(); If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/models/tsb.html.mdx b/statsforecast/docs/models/tsb.html.mdx index 28f3d6b5..8d0c89ef 100644 --- a/statsforecast/docs/models/tsb.html.mdx +++ b/statsforecast/docs/models/tsb.html.mdx @@ -487,7 +487,7 @@ result If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/tutorials/crossvalidation.html.mdx b/statsforecast/docs/tutorials/crossvalidation.html.mdx index 78d4a398..eb1fa83c 100644 --- a/statsforecast/docs/tutorials/crossvalidation.html.mdx +++ b/statsforecast/docs/tutorials/crossvalidation.html.mdx @@ -85,7 +85,7 @@ Y_df.head() | 4 | H1 | 5 | 511.0 | The input to -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) is a data frame in [long format](https://www.theanalysisfactor.com/wide-and-long-data/) with three columns: `unique_id`, `ds` and y: @@ -126,11 +126,11 @@ For this example, we’ll use StastForecast [AutoETS](https://nixtla.github.io/statsforecast/models.html#autoets). We first need to import it from `statsforecast.models` and then we need to instantiate a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object. The -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object has the following parameters: - models: a list of models. Select the models you want from @@ -164,13 +164,13 @@ sf = StatsForecast( ## Perform time series cross-validation Once the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast)object +[`StatsForecast`](src/core/core.html#statsforecast)object has been instantiated, we can use the -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method, which takes the following arguments: - `df`: training data frame with - [`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) + [`StatsForecast`](src/core/core.html#statsforecast) format - `h` (int): represents the h steps into the future that will be forecasted @@ -257,7 +257,7 @@ The function to compute the RMSE takes two arguments: 1. The actual values. 2. The forecasts, in this case, - [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets). + [`AutoETS`](src/core/models.html#autoets). ```python diff --git a/statsforecast/docs/tutorials/electricityloadforecasting.html.mdx b/statsforecast/docs/tutorials/electricityloadforecasting.html.mdx index 99083583..827211e0 100644 --- a/statsforecast/docs/tutorials/electricityloadforecasting.html.mdx +++ b/statsforecast/docs/tutorials/electricityloadforecasting.html.mdx @@ -29,7 +29,7 @@ hourly PJM electricity load data. The original data can be found In this example we will use the following libraries: -- [`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast). +- [`StatsForecast`](src/core/core.html#statsforecast). Lightning ⚡️ fast forecasting with statistical and econometric models. Includes the MSTL model for multiple seasonalities. - [`Prophet`](https://github.com/facebook/prophet). Benchmark model @@ -107,19 +107,19 @@ in production. ### MSTL model The -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) (Multiple Seasonal-Trend decomposition using LOESS) model, originally developed by [Kasun Bandara, Rob J Hyndman and Christoph Bergmeir](https://arxiv.org/abs/2107.13462), decomposes the time series in multiple seasonalities using a Local Polynomial Regression (LOESS). Then it forecasts the trend using a custom non-seasonal model and each seasonality using a -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) model. -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) contains a fast implementation of the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model. Also, the decomposition of the time series can be calculated. @@ -135,7 +135,7 @@ every 24 \* 7 (Daily) hours. Therefore, we will use `[24, 24 * 7]` as the seasonalities that the MSTL model receives. We must also specify the manner in which the trend will be forecasted. In this case we will use the -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model. @@ -147,7 +147,7 @@ mstl = MSTL( ``` Once the model is instantiated, we have to instantiate the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class to create forecasts. @@ -172,14 +172,14 @@ sf = sf.fit(df=df) Once the model is fitted, we can access the decomposition using the `fitted_` attribute of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast). +[`StatsForecast`](src/core/core.html#statsforecast). This attribute stores all relevant information of the fitted models for each of the time series. In this case we are fitting a single model for a single time series, so by accessing the fitted\_ location \[0, 0\] we will find the relevant information of our model. The -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) class generates a `model_` attribute that contains the way the series was decomposed. @@ -215,11 +215,11 @@ plt.show() We observe that there is a clear trend towards the high (orange line). This component would be predicted with the -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model. We can also observe that every 24 hours and every `24 * 7` hours there is a very well defined pattern. These two components will be forecast separately using a -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) model. #### Produce forecasts @@ -284,7 +284,7 @@ def plot_forecasts(y_hist, y_true, y_pred, models): #### Split Train/Test sets To validate the accuracy of the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model, we will show its performance on unseen data. We will use a classical time series technique that consists of dividing the data into a training set and a test set. We will leave the last 24 observations @@ -300,13 +300,13 @@ df_train = df.drop(df_test.index) #### MSTL model In addition to the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model, we will include the -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) model as a benchmark to validate the added value of the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model. Including -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) models is as simple as adding them to the list of models to be fitted. @@ -366,7 +366,7 @@ plot_series(df_train, df_test.merge(forecasts_test), level=[90], max_insample_le ![](/statsforecast/docs/tutorials/ElectricityLoadForecasting_files/figure-markdown_strict/cell-21-output-1.png) Let’s look at those produced only by -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl). +[`MSTL`](src/core/models.html#mstl). ```python @@ -376,7 +376,7 @@ plot_series(df_train, df_test.merge(forecasts_test), level=[90], max_insample_le ![](/statsforecast/docs/tutorials/ElectricityLoadForecasting_files/figure-markdown_strict/cell-22-output-1.png) We note that -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) produces very accurate forecasts that follow the behavior of the time series. Now let us calculate numerically the accuracy of the model. We will use the following metrics: `MAE`, `MAPE`, `MASE`, `RMSE`, `SMAPE`. @@ -415,9 +415,9 @@ eval_df ``` We observe that -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) has an improvement of about 35% over the -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) method in the test set measured in `MASE`. #### Comparison with Prophet @@ -426,7 +426,7 @@ One of the most widely used models for time series forecasting is `Prophet`. This model is known for its ability to model different seasonalities (weekly, daily yearly). We will use this model as a benchmark to see if the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) adds value for this time series. @@ -487,7 +487,7 @@ times We observe that the time required for `Prophet` to perform the fit and predict pipeline is greater than -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl). +[`MSTL`](src/core/models.html#mstl). Let’s look at the forecasts produced by `Prophet`. @@ -534,9 +534,9 @@ eval_df In terms of accuracy, `Prophet` is not able to produce better forecasts than the -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) model, however, the -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) model improves `Prophet`’s forecasts by 45% (`MASE`). #### Comparison with NeuralProphet @@ -639,7 +639,7 @@ times We observe that `NeuralProphet` requires a longer processing time than `Prophet` and -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl). +[`MSTL`](src/core/models.html#mstl). ```python @@ -685,7 +685,7 @@ eval_df With respect to numerical evaluation, `NeuralProphet` improves the results of `Prophet`, as expected, however, -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) improves over `NeuralProphet`’s foreacasts by 44% (`MASE`). > **Important** @@ -698,7 +698,7 @@ improves over `NeuralProphet`’s foreacasts by 44% (`MASE`). ## Conclusion In this post we introduced -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl), +[`MSTL`](src/core/models.html#mstl), a model originally developed by [Kasun Bandara, Rob Hyndman and Christoph Bergmeir](https://arxiv.org/abs/2107.13462) capable of handling time series with multiple seasonalities. We also showed that diff --git a/statsforecast/docs/tutorials/electricitypeakforecasting.html.mdx b/statsforecast/docs/tutorials/electricitypeakforecasting.html.mdx index 1b49009f..4e09704d 100644 --- a/statsforecast/docs/tutorials/electricitypeakforecasting.html.mdx +++ b/statsforecast/docs/tutorials/electricitypeakforecasting.html.mdx @@ -25,7 +25,7 @@ therefore save on electricity bills by reducing the coincident peak demand. In this example we will train an -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) (Multiple Seasonal-Trend decomposition using LOESS) model on historic load data to forecast day-ahead peaks on September 2022. Multiple seasonality is traditionally present in low sampled electricity data. @@ -34,7 +34,7 @@ specific hours of the day such as 6:00pm vs 3:00am or for specific days such as Sunday vs Friday. First, we will load ERCOT historic demand, then we will use the -[`StatsForecast.cross_validation`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.cross_validation) +[`StatsForecast.cross_validation`](src/core/core.html#statsforecast.cross_validation) method to fit the MSTL model and forecast daily load during September. Finally, we show how to use the forecasts to detect the coincident peak. @@ -84,7 +84,7 @@ Y_df = pd.read_csv('https://datasets-nixtla.s3.amazonaws.com/ERCOT-clean.csv', p ``` Plot the series using the `plot` method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class. This method prints up to 8 random series from the dataset and is useful for basic EDA. @@ -123,7 +123,7 @@ model. > [here](https://nixtla.github.io/statsforecast/examples/multipleseasonalities.html) Import the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class and the models you need. @@ -142,7 +142,7 @@ seasonalities. See [this link](https://robjhyndman.com/hyndsight/seasonal-periods/) for a detailed explanation on how to set seasonal lengths. In this example we use the -[`SklearnModel`](https://Nixtla.github.io/statsforecast/src/core/models.html#sklearnmodel) +[`SklearnModel`](src/core/models.html#sklearnmodel) with a `LinearRegression` model for the trend component, however, any StatsForecast model can be used. The complete list of models is available [here](https://nixtla.github.io/statsforecast/models.html). @@ -172,7 +172,7 @@ models = [ ``` We fit the model by instantiating a -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following required parameters: - `models`: a list of models. Select the models you want from @@ -202,7 +202,7 @@ sf = StatsForecast( > none) The -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method allows the user to simulate multiple historic forecasts, greatly simplifying pipelines by replacing for loops with `fit` and `predict` methods. This method re-trains the model and forecast each window. See @@ -211,7 +211,7 @@ tutorial](https://nixtla.github.io/statsforecast/examples/getting_started_comple for an animation of how the windows are defined. Use the -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method to produce all the daily forecasts for September. To produce daily forecasts set the forecasting horizon `h` as 24. In this example we are simulating deploying the pipeline during September, so set the @@ -244,7 +244,7 @@ cv_df.head() > **Important** > > When using -> [`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +> [`cross_validation`](src/mfles.html#cross_validation) > make sure the forecasts are produced at the desired timestamps. Check > the `cutoff` column which specifices the last timestamp before the > forecasting window. @@ -304,7 +304,7 @@ plt.legend() > In this example we only include September. However, MSTL can correctly > predict the peaks for the 4 months of 2022. You can try this by > increasing the `nwindows` parameter of -> [`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +> [`cross_validation`](src/mfles.html#cross_validation) > or filtering the `Y_df` dataset. The complete run for all months take > only 10 minutes. diff --git a/statsforecast/docs/tutorials/multipleseasonalities.html.mdx b/statsforecast/docs/tutorials/multipleseasonalities.html.mdx index 7a693bfd..b5ec4707 100644 --- a/statsforecast/docs/tutorials/multipleseasonalities.html.mdx +++ b/statsforecast/docs/tutorials/multipleseasonalities.html.mdx @@ -25,7 +25,7 @@ Traditional statistical models are not able to model more than one seasonal length. In this example, we will show how to model the two seasonalities efficiently using Multiple Seasonal-Trend decompositions with LOESS -([`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl)). +([`MSTL`](src/core/models.html#mstl)). For this example, we will use hourly electricity load data from Pennsylvania, New Jersey, and Maryland (PJM). The original data can be @@ -37,7 +37,7 @@ First, we will load the data, then we will use the `StatsForecast.fit` and `StatsForecast.predict` methods to predict the next 24 hours. We will then decompose the different elements of the time series into trends and its multiple seasonalities. At the end, you will use the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) for production-ready forecasting. **Outline** @@ -106,7 +106,7 @@ StatsForecast can handle unsorted data, however, for plotting purposes, it is convenient to sort the data frame. Plot the series using the `plot` method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class. This method prints up to 8 random series from the dataset and is useful for basic EDA. In this case, it will print just one series given that we have just one unique_id. @@ -135,14 +135,14 @@ computationally efficient methods. ## Fit an MSTL model The -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) (Multiple Seasonal-Trend decompositions using LOESS) model, originally developed by [Kasun Bandara, Rob J Hyndman and Christoph Bergmeir](https://arxiv.org/abs/2107.13462), decomposes the time series in multiple seasonalities using a Local Polynomial Regression (LOESS). Then it forecasts the trend using a non-seasonal model and each seasonality using a -[`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) +[`SeasonalNaive`](src/core/models.html#seasonalnaive) model. You can choose the non-seasonal model you want to use to forecast the trend component of the MSTL model. In this example, we will use an AutoARIMA. @@ -158,12 +158,12 @@ First, we must define the model parameters. As mentioned before, the electricity load presents seasonalities every 24 hours (Hourly) and every 24 \* 7 (Daily) hours. Therefore, we will use `[24, 24 * 7]` for season length. The trend component will be forecasted with an -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model. (You can also try with: -[`AutoTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#autotheta), -[`AutoCES`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoces), +[`AutoTheta`](src/core/models.html#autotheta), +[`AutoCES`](src/core/models.html#autoces), and -[`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets)) +[`AutoETS`](src/core/models.html#autoets)) ```python @@ -176,7 +176,7 @@ models = [MSTL( ``` We fit the models by instantiating a new -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) object with the following required parameters: - `models`: a list of models. Select the models you want from @@ -228,14 +228,14 @@ sf = sf.fit(df=df) Once the model is fitted, access the decomposition using the `fitted_` attribute of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast). +[`StatsForecast`](src/core/core.html#statsforecast). This attribute stores all relevant information of the fitted models for each of the time series. In this case, we are fitting a single model for a single time series, so by accessing the fitted\_ location \[0, 0\] we will find the relevant information of our model. The -[`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) +[`MSTL`](src/core/models.html#mstl) class generates a `model_` attribute that contains the way the series was decomposed. @@ -330,7 +330,7 @@ sf.plot(df, forecasts, max_insample_length=24 * 7) If you want to gain speed in productive settings where you have multiple series or models we recommend using the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method instead of `.fit` and `.predict`. The main difference is that the `.forecast` doest not store the fitted diff --git a/statsforecast/docs/tutorials/statisticalneuralmethods.html.mdx b/statsforecast/docs/tutorials/statisticalneuralmethods.html.mdx index f8c494e2..47a623c8 100644 --- a/statsforecast/docs/tutorials/statisticalneuralmethods.html.mdx +++ b/statsforecast/docs/tutorials/statisticalneuralmethods.html.mdx @@ -39,21 +39,21 @@ paradigms: - Baseline models: These models are simple yet often highly effective for providing an initial perspective on the forecasting problem. We will use - [`SeasonalNaive`](https://Nixtla.github.io/statsforecast/src/core/models.html#seasonalnaive) + [`SeasonalNaive`](src/core/models.html#seasonalnaive) and - [`HistoricAverage`](https://Nixtla.github.io/statsforecast/src/core/models.html#historicaverage) + [`HistoricAverage`](src/core/models.html#historicaverage) models for this category. - Intermittent models: For series with sporadic, non-continuous demand, we will utilize models like - [`CrostonOptimized`](https://Nixtla.github.io/statsforecast/src/core/models.html#crostonoptimized), - [`IMAPA`](https://Nixtla.github.io/statsforecast/src/core/models.html#imapa), + [`CrostonOptimized`](src/core/models.html#crostonoptimized), + [`IMAPA`](src/core/models.html#imapa), and - [`ADIDA`](https://Nixtla.github.io/statsforecast/src/core/models.html#adida). + [`ADIDA`](src/core/models.html#adida). These models are particularly suited for handling zero-inflated series. - State Space Models: These are statistical models that use mathematical descriptions of a system to make predictions. The - [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets) + [`AutoETS`](src/core/models.html#autoets) model from the statsforecast library falls under this category. *[MLForecast](https://github.com/Nixtla/mlforecast)* @@ -153,7 +153,7 @@ Y_df['unique_id'] = Y_df['unique_id'].astype(str) # Basic Plotting Plot some series using the plot method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class. This method prints 8 random series from the dataset and is useful for basic [EDA](https://nixtla.github.io/statsforecast/core.html#statsforecast.plot). @@ -192,7 +192,7 @@ StatsForecast.plot(Y_df, unique_ids=["FOODS_3_432_TX_2"], engine ='matplotlib') ## StatsForecast -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) is a comprehensive library providing a suite of popular univariate time series forecasting models, all designed with a focus on high performance and scalability. @@ -222,7 +222,7 @@ forecasting: computations across multiple nodes in a cluster, making it a go-to solution for large-scale time series forecasting tasks. -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) receives a list of models to fit each time series. Since we are dealing with Daily data, it would be benefitial to use 7 as seasonality. @@ -576,7 +576,7 @@ sf.plot(Y_df, fcst_df, max_insample_length=28 * 3, # Validate Model’s Performance The three libraries - -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast), +[`StatsForecast`](src/core/core.html#statsforecast), `MLForecast`, and `NeuralForecast` - offer out-of-the-box cross-validation capabilities specifically designed for time series. This allows us to evaluate the model’s performance using historical data @@ -593,9 +593,9 @@ Practice ## Cross Validation in StatsForecast The -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method from the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class accepts the following arguments: - `df`: A DataFrame representing the training data. @@ -660,7 +660,7 @@ cv_df.head() ## MLForecast The -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method from the `MLForecast` class takes the following arguments. - `data`: training data frame @@ -1027,8 +1027,8 @@ sf.plot(Y_df, fcst_df, max_insample_length=28 * 3) - Train the statistical models in the full dataset. - Increase the number of `num_samples` in the neural auto models. - Include other models such as - [`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta), - [`ARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#arima), + [`Theta`](src/core/models.html#theta), + [`ARIMA`](src/core/models.html#arima), `RNN`, `LSTM`, … # Further materials diff --git a/statsforecast/index.html.mdx b/statsforecast/index.html.mdx index 41e8d256..d10e06bf 100644 --- a/statsforecast/index.html.mdx +++ b/statsforecast/index.html.mdx @@ -10,7 +10,7 @@ title: StatsForecast ⚡️ ## Installation You can install -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) with: @@ -61,19 +61,19 @@ best practices.** Current Python alternatives for statistical models are slow, inaccurate and don’t scale well. So we created a library that can be used to forecast in production environments or as benchmarks. -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) includes an extensive battery of models that can efficiently fit millions of time series. ## Features - Fastest and most accurate implementations of - [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima), - [`AutoETS`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoets), - [`AutoCES`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoces), - [`MSTL`](https://Nixtla.github.io/statsforecast/src/core/models.html#mstl) + [`AutoARIMA`](src/core/models.html#autoarima), + [`AutoETS`](src/core/models.html#autoets), + [`AutoCES`](src/core/models.html#autoces), + [`MSTL`](src/core/models.html#mstl) and - [`Theta`](https://Nixtla.github.io/statsforecast/src/core/models.html#theta) + [`Theta`](src/core/models.html#theta) in Python. - Out-of-the-box compatibility with Spark, Dask, and Ray. - Probabilistic Forecasting and Confidence Intervals. diff --git a/statsforecast/src/adapters.prophet.html.mdx b/statsforecast/src/adapters.prophet.html.mdx index 650d6cd2..f384e079 100644 --- a/statsforecast/src/adapters.prophet.html.mdx +++ b/statsforecast/src/adapters.prophet.html.mdx @@ -54,7 +54,7 @@ interface. This class receives as parameters the same as prophet.Prophet and uses a `models.AutoARIMA` backend. If your forecasting pipeline uses Prophet the -[`AutoARIMAProphet`](https://Nixtla.github.io/statsforecast/src/adapters.prophet.html#autoarimaprophet) +[`AutoARIMAProphet`](src/adapters.prophet.html#autoarimaprophet) adapter helps to easily substitute Prophet with an AutoARIMA.\* | | **Type** | **Default** | **Details** | @@ -72,7 +72,7 @@ adapter helps to easily substitute Prophet with an AutoARIMA.\* | holidays_prior_scale | float | 10.0 | | | changepoint_prior_scale | float | 0.05 | | | mcmc_samples | int | 0 | | -| interval_width | float | 0.8 | Uncertainty forecast intervals width. [`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast)’s level | +| interval_width | float | 0.8 | Uncertainty forecast intervals width. [`StatsForecast`](src/core/core.html#statsforecast)’s level | | uncertainty_samples | int | 1000 | | | stan_backend | NoneType | None | | | d | NoneType | None | | @@ -125,7 +125,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source |------|------------------|-------------------------|-------------------------| | df | pandas.DataFrame | | DataFrame with columns ds (date type) and y, the time series. | | disable_seasonal_features | bool | True | Disable Prophet’s seasonal features. | -| **Returns** | **AutoARIMAProphet** | | **Adapter object with [`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) fitted model.** | +| **Returns** | **AutoARIMAProphet** | | **Adapter object with [`AutoARIMA`](src/core/models.html#autoarima) fitted model.** | ------------------------------------------------------------------------ @@ -164,14 +164,14 @@ appearances). The original CSV is available [here](https://github.com/facebook/prophet/blob/main/examples/example_wp_log_peyton_manning.csv). Here we show that -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) can improve performance by borrowing the `Prophet`’s feature preprocessing. ### Inputs The -[`AutoARIMAProphet`](https://Nixtla.github.io/statsforecast/src/adapters.prophet.html#autoarimaprophet) +[`AutoARIMAProphet`](src/adapters.prophet.html#autoarimaprophet) adapter uses `Prophet`‘s inputs, a pandas dataframe with two columns: `ds` and `y`. The `ds` (datestamp) column should be of a format expected by Pandas, ideally ’YYYY-MM-DD’ for a date or ‘YYYY-MM-DD HH:MM:SS’ for @@ -205,14 +205,14 @@ fig = m.plot(forecast) ``` Here we forecast with -[`AutoARIMAProphet`](https://Nixtla.github.io/statsforecast/src/adapters.prophet.html#autoarimaprophet) +[`AutoARIMAProphet`](src/adapters.prophet.html#autoarimaprophet) adapter without external regressors. It inherits the `Prophet` constructor as well as its `fit` and `predict` methods. With the class -[`AutoARIMAProphet`](https://Nixtla.github.io/statsforecast/src/adapters.prophet.html#autoarimaprophet) +[`AutoARIMAProphet`](src/adapters.prophet.html#autoarimaprophet) you can simply substitute `Prophet` and you’ll be training an -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model without changing anything in your forecasting pipeline. @@ -287,9 +287,9 @@ fig = m.plot(forecast) ``` The class -[`AutoARIMAProphet`](https://Nixtla.github.io/statsforecast/src/adapters.prophet.html#autoarimaprophet) +[`AutoARIMAProphet`](src/adapters.prophet.html#autoarimaprophet) adapter allows to handle these scenarios to fit an -[`AutoARIMA`](https://Nixtla.github.io/statsforecast/src/core/models.html#autoarima) +[`AutoARIMA`](src/core/models.html#autoarima) model with exogenous variables. You can enjoy your Prophet pipelines with the improved performance of a diff --git a/statsforecast/src/core/core.html.mdx b/statsforecast/src/core/core.html.mdx index 1702acef..97bab853 100644 --- a/statsforecast/src/core/core.html.mdx +++ b/statsforecast/src/core/core.html.mdx @@ -6,13 +6,13 @@ title: Core Methods The core methods of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) are: - `StatsForecast.fit` - `StatsForecast.predict` -- [`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) -- [`StatsForecast.cross_validation`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.cross_validation) +- [`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) +- [`StatsForecast.cross_validation`](src/core/core.html#statsforecast.cross_validation) - `StatsForecast.plot` ------------------------------------------------------------------------ @@ -29,20 +29,20 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source > ``` \*The -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class allows you to efficiently fit multiple -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) models for large sets of time series. It operates on a DataFrame `df` with at least three columns ids, times and targets. The class has memory-efficient -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method that avoids storing partial model outputs. While the `StatsForecast.fit` and `StatsForecast.predict` methods with Scikit-learn interface store the fitted models. The -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class offers parallelization utilities with Dask, Spark and Ray back-ends. See distributed computing example [here](https://github.com/Nixtla/statsforecast/tree/main/experiments/ray).\* @@ -130,7 +130,7 @@ fitted models for later inspection.\* | id_col | str | unique_id | Column that identifies each serie. | | time_col | str | ds | Column that identifies each timestep, its values can be timestamps or integers. | | target_col | str | y | Column that contains the target. | -| **Returns** | **StatsForecast** | | **Returns with stored [`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) fitted `models`.** | +| **Returns** | **StatsForecast** | | **Returns with stored [`StatsForecast`](src/core/core.html#statsforecast) fitted `models`.** | ------------------------------------------------------------------------ @@ -185,7 +185,7 @@ analogous to Scikit-Learn `fit_predict` without storing information. It requires the forecast horizon `h` in advance. In contrast to -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) this method stores partial models outputs.\* | | **Type** | **Default** | **Details** | @@ -274,12 +274,12 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source \*Access insample predictions. After executing -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast), +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast), you can access the insample prediction values for each model. To get them, you need to pass `fitted=True` to the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method and then use the -[`StatsForecast.forecast_fitted_values`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast_fitted_values) +[`StatsForecast.forecast_fitted_values`](src/core/core.html#statsforecast.forecast_fitted_values) method.\* @@ -329,7 +329,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source \*Temporal Cross-Validation. Efficiently fits a list of -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) models through multiple training windows, in either chained or rolled manner. @@ -390,10 +390,10 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source \*Access insample cross validated predictions. After executing -[`StatsForecast.cross_validation`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.cross_validation), +[`StatsForecast.cross_validation`](src/core/core.html#statsforecast.cross_validation), you can access the insample prediction values for each model and window. To get them, you need to pass `fitted=True` to the -[`StatsForecast.cross_validation`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.cross_validation) +[`StatsForecast.cross_validation`](src/core/core.html#statsforecast.cross_validation) method and then use the `StatsForecast.cross_validation_fitted_values` method.\* @@ -517,7 +517,7 @@ res = fcst.forecast(df=series, h=14) ## Integer datestamp The -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) class can also receive integers as datestamp, the following example shows how to do it. @@ -570,7 +570,7 @@ int_ds_cv Every column after **y** is considered an external regressor and will be passed to the models that allow them. If you use them you must supply the future values to the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method. @@ -639,7 +639,7 @@ xreg_res_cv = fcst.cross_validation(df=series_train, h=3, test_size=5, n_windows ## Prediction intervals You can pass the argument `level` to the -[`StatsForecast.forecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast.forecast) +[`StatsForecast.forecast`](src/core/core.html#statsforecast.forecast) method to calculate prediction intervals. Not all models can calculate them at the moment, so we will only obtain the intervals of those models that have it implemented. diff --git a/statsforecast/src/core/distributed.fugue.html.mdx b/statsforecast/src/core/distributed.fugue.html.mdx index 892cb4b5..13e62453 100644 --- a/statsforecast/src/core/distributed.fugue.html.mdx +++ b/statsforecast/src/core/distributed.fugue.html.mdx @@ -111,7 +111,7 @@ StatsForecast models.\* | df | AnyDataFrame | DataFrame with ids, times, targets and exogenous. | | freq | Union | Frequency of the data. Must be a valid pandas or polars offset alias, or an integer. | | models | List | List of instantiated objects models.StatsForecast. | -| fallback_model | Optional | Any, optional (default=None)
Model to be used if a model fails.
Only works with the `forecast` and [`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) methods. | +| fallback_model | Optional | Any, optional (default=None)
Model to be used if a model fails.
Only works with the `forecast` and [`cross_validation`](src/mfles.html#cross_validation) methods. | | X_df | Optional | DataFrame with ids, times and future exogenous. | | h | int | Forecast horizon. | | level | Optional | Confidence levels between 0 and 100 for prediction intervals. | @@ -159,7 +159,7 @@ measurements by increasing the test’s length and diversity.\* | df | AnyDataFrame | DataFrame with ids, times, targets and exogenous. | | freq | Union | Frequency of the data. Must be a valid pandas or polars offset alias, or an integer. | | models | List | List of instantiated objects models.StatsForecast. | -| fallback_model | Optional | Any, optional (default=None)
Model to be used if a model fails.
Only works with the `forecast` and [`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) methods. | +| fallback_model | Optional | Any, optional (default=None)
Model to be used if a model fails.
Only works with the `forecast` and [`cross_validation`](src/mfles.html#cross_validation) methods. | | h | int | Forecast horizon. | | n_windows | int | Number of windows used for cross validation. | | step_size | int | Step size between each window. | @@ -177,11 +177,11 @@ measurements by increasing the test’s length and diversity.\* ## Dask Distributed Predictions Here we provide an example for the distribution of the -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) predictions using `Fugue` to execute the code in a Dask cluster. To do it we instantiate the -[`FugueBackend`](https://Nixtla.github.io/statsforecast/src/core/distributed.fugue.html#fuguebackend) +[`FugueBackend`](src/core/distributed.fugue.html#fuguebackend) class with a `DaskExecutionEngine`. @@ -207,7 +207,7 @@ engine = DaskExecutionEngine(dask_client=dask_client) ``` We have simply create the class to the usual -[`StatsForecast`](https://Nixtla.github.io/statsforecast/src/core/core.html#statsforecast) +[`StatsForecast`](src/core/core.html#statsforecast) instantiation. @@ -244,7 +244,7 @@ yy = sf.forecast_fitted_values().compute() ### Distributed Cross-Validation For extremely fast distributed temporcal cross-validation we use -[`cross_validation`](https://Nixtla.github.io/statsforecast/src/mfles.html#cross_validation) +[`cross_validation`](src/mfles.html#cross_validation) method that operates like the original [StatsForecast.cross_validation](https://nixtla.github.io/statsforecast/src/core/core.html#statsforecast.cross_validation) method. diff --git a/statsforecast/src/core/models.html.mdx b/statsforecast/src/core/models.html.mdx index 9c5aa8a4..0f27d0e6 100644 --- a/statsforecast/src/core/models.html.mdx +++ b/statsforecast/src/core/models.html.mdx @@ -98,7 +98,7 @@ Information Criterion (AICc).\* | approximation | Optional | False | If True, conditional sums-of-squares estimation, final MLE. | | method | Optional | None | Fitting method between maximum likelihood or sums-of-squares. | | truncate | Optional | None | Observations truncated series used in model selection. | -| test | str | kpss | Unit root test to use. See [`ndiffs`](https://Nixtla.github.io/statsforecast/src/arima.html#ndiffs) for details. | +| test | str | kpss | Unit root test to use. See [`ndiffs`](src/arima.html#ndiffs) for details. | | test_kwargs | Optional | None | Unit root test additional arguments. | | seasonal_test | str | seas | Selection method for seasonal differences. | | seasonal_test_kwargs | Optional | None | Seasonal unit root test arguments. | @@ -4448,7 +4448,7 @@ target="_blank" style={{ float: "right", fontSize: "smaller" }}>source |------|------------------|-------------------------|-------------------------| | season_length | int | 1 | Number of observations per unit of time. Ex: 24 Hourly data. | | decomposition_type | str | multiplicative | Sesonal decomposition type, ‘multiplicative’ (default) or ‘additive’. | -| alias | str | OptimizedTheta | Custom name of the model. Default [`OptimizedTheta`](https://Nixtla.github.io/statsforecast/src/core/models.html#optimizedtheta). | +| alias | str | OptimizedTheta | Custom name of the model. Default [`OptimizedTheta`](src/core/models.html#optimizedtheta). | | prediction_intervals | Optional | None | Information to compute conformal prediction intervals.
By default, the model will compute the native prediction
intervals. | ------------------------------------------------------------------------