mirror of
https://github.com/saymrwulf/prophet.git
synced 2026-07-19 19:00:52 +00:00
Rename master to main (#2090)
This commit is contained in:
Cuong Duong
GitHub
parent
ba9a5a2c6e
commit
4af7a45480
10 changed files with 115 additions and 119 deletions
4
.github/workflows/build-and-test.yml
vendored
4
.github/workflows/build-and-test.yml
vendored
|
|
@ -2,9 +2,9 @@ name: Build
|
|||
|
||||
on:
|
||||
push:
|
||||
branches: [ master ]
|
||||
branches: [ main ]
|
||||
pull_request:
|
||||
branches: [ master ]
|
||||
branches: [ main ]
|
||||
|
||||
env:
|
||||
CMDSTAN_VERSION: "2.26.1"
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ See [CONTRIBUTING.md](./CONTRIBUTING.md) for details on how to add or modify con
|
|||
|
||||
## Jupyter Notebooks
|
||||
|
||||
Most of the `doc` pages are generated from [Jupyter notebooks](http://jupyter.org/) in the [notebooks](https://github.com/facebook/prophet/tree/master/notebooks) directory at the base of the source tree. Please make changes there and then rebuild the docs:
|
||||
Most of the `doc` pages are generated from [Jupyter notebooks](http://jupyter.org/) in the [notebooks](https://github.com/facebook/prophet/tree/main/notebooks) directory at the base of the source tree. Please make changes there and then rebuild the docs:
|
||||
|
||||
```
|
||||
$ cd docs
|
||||
|
|
@ -23,7 +23,7 @@ The requirements for running a GitHub pages site locally is described in [GitHub
|
|||
|
||||
> If you have run the site before, you can start with step 1 and then move on to step 5.
|
||||
|
||||
1. Ensure that you are in the same directory where this `README.md` exists (e.g., it could be in `/docs` on `master`, in the root of a `gh-pages` branch, etc). The below RubyGems commands, etc must be run from there.
|
||||
1. Ensure that you are in the same directory where this `README.md` exists (e.g., it could be in `/docs` on `main`, in the root of a `gh-pages` branch, etc). The below RubyGems commands, etc must be run from there.
|
||||
|
||||
1. Make sure you have Ruby and [RubyGems](https://rubygems.org/) installed.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ development environment. This should contain the required dependencies.
|
|||
```bash
|
||||
$ cd python
|
||||
|
||||
# with Anaconda
|
||||
# with Anaconda
|
||||
$ conda create -n prophet
|
||||
$ conda activate prophet
|
||||
$ pip install -r requirements.txt
|
||||
|
|
@ -58,7 +58,7 @@ $ pip install -r requirements.txt
|
|||
|
||||
Dependencies can be managed through [``Packrat``](https://rstudio.github.io/packrat/) or [``renv``](https://rstudio.github.io/renv/articles/renv.html).
|
||||
|
||||
For ``renv``, you must first initialise a new project local environment.
|
||||
For ``renv``, you must first initialise a new project local environment.
|
||||
```R
|
||||
> setwd("path/to/prophet/R") # set R subdirectory as working directory
|
||||
> install.packages('renv')
|
||||
|
|
@ -67,13 +67,13 @@ For ``renv``, you must first initialise a new project local environment.
|
|||
|
||||
This should also install the dependencies listed in the DESCRIPTION automatically. Any new R packages can be installed as they are needed in the project.
|
||||
|
||||
You can save the state of the project:
|
||||
You can save the state of the project:
|
||||
|
||||
```R
|
||||
> renv::snapshot()
|
||||
```
|
||||
|
||||
or load the environment:
|
||||
or load the environment:
|
||||
|
||||
```R
|
||||
> renv::restore()
|
||||
|
|
@ -81,7 +81,7 @@ or load the environment:
|
|||
|
||||
## 3. Building a development version of Prophet
|
||||
|
||||
The next step is to build and install the development version of prophet in the environment you have just created.
|
||||
The next step is to build and install the development version of prophet in the environment you have just created.
|
||||
|
||||
### Python
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ $ python # start an interpreter
|
|||
```
|
||||
|
||||
This will create the new environment, and not touch any of your existing environments,
|
||||
nor any existing Python installation.
|
||||
nor any existing Python installation.
|
||||
|
||||
```bash
|
||||
# to view your environments:
|
||||
|
|
@ -122,7 +122,7 @@ This will build and install the local version of the prophet package. Then from
|
|||
|
||||
## 4. Creating a branch
|
||||
|
||||
You want your master branch to reflect only production-ready code, so create a
|
||||
You want your main branch to reflect only production-ready code, so create a
|
||||
feature branch for making your changes. For example:
|
||||
|
||||
```bash
|
||||
|
|
@ -134,14 +134,14 @@ changes in this branch specific to one bug or feature so it is clear
|
|||
what the branch brings to *prophet*. You can have many "new-features"
|
||||
and switch in between them using the ``git checkout`` command.
|
||||
|
||||
To update this branch, you need to retrieve the changes from the master branch:
|
||||
To update this branch, you need to retrieve the changes from the main branch:
|
||||
|
||||
```bash
|
||||
$ git fetch upstream
|
||||
$ git rebase upstream/master
|
||||
$ git rebase upstream/main
|
||||
```
|
||||
|
||||
This will replay your commits on top of the latest *prophet* git master. If this
|
||||
This will replay your commits on top of the latest *prophet* git `main`. If this
|
||||
leads to merge conflicts, you must resolve these before submitting your pull
|
||||
request. If you have uncommitted changes, you will need to ``git stash`` them
|
||||
prior to updating. This will effectively store your changes and they can be
|
||||
|
|
@ -154,9 +154,9 @@ Adding tests is one of the most common requests after code is pushed to prophet.
|
|||
|
||||
### Python
|
||||
|
||||
Prophet uses the ``unittest`` package for running tests in Python and ``testthat`` package for testing in R. All tests should go into the tests subdirectory in either the Python or R folders.
|
||||
Prophet uses the ``unittest`` package for running tests in Python and ``testthat`` package for testing in R. All tests should go into the tests subdirectory in either the Python or R folders.
|
||||
|
||||
The entire test suite can be run by typing:
|
||||
The entire test suite can be run by typing:
|
||||
```bash
|
||||
$ python setup.py tests
|
||||
```
|
||||
|
|
@ -185,7 +185,7 @@ or for just running a single test script like ``test_diagnostics.R`` from the R
|
|||
|
||||
## 6. Generating documentation
|
||||
|
||||
Most of the `doc` pages are generated from [Jupyter notebooks](http://jupyter.org/) in the [notebooks](https://github.com/facebook/prophet/tree/master/notebooks) directory at the base of the source tree. Please make changes there and then rebuild the docs:
|
||||
Most of the `doc` pages are generated from [Jupyter notebooks](http://jupyter.org/) in the [notebooks](https://github.com/facebook/prophet/tree/main/notebooks) directory at the base of the source tree. Please make changes there and then rebuild the docs:
|
||||
|
||||
```bash
|
||||
$ cd docs
|
||||
|
|
@ -194,12 +194,12 @@ $ make notebooks
|
|||
|
||||
Make sure you have installed [rpy2](https://rpy2.bitbucket.io/) so that the R code can be run as well.
|
||||
|
||||
In R, the documentation for the source code must also generated if new parameters are added or a new function is created. This is documented with ``roxygen``.
|
||||
In R, the documentation for the source code must also generated if new parameters are added or a new function is created. This is documented with ``roxygen``.
|
||||
|
||||
Run the command below before submitting a PR with any changes to the R code to update the function documentation:
|
||||
|
||||
```R
|
||||
> devtools::document()
|
||||
> devtools::document()
|
||||
```
|
||||
|
||||
## 7. Committing your code
|
||||
|
|
@ -263,12 +263,12 @@ When you’re ready to ask for a code review, file a pull request. Before you do
|
|||
1. Navigate to your repository on GitHub – https://github.com/your-user-name/prophet
|
||||
2. Click on Branches
|
||||
3. Click on the Compare button for your feature branch
|
||||
4. Select the base and compare branches, if necessary. This will be master and new-feature, respectively.
|
||||
4. Select the base and compare branches, if necessary. This will be `main` and new-feature, respectively.
|
||||
|
||||
|
||||
## 10. Making a pull request
|
||||
|
||||
If everything looks good, you are ready to make a pull request. A pull request is how code from a local repository becomes available to the GitHub community and can be reviewed and eventually merged into the master version. This pull request and its associated changes will eventually be committed to the master branch and available in the next release. To submit a pull request:
|
||||
If everything looks good, you are ready to make a pull request. A pull request is how code from a local repository becomes available to the GitHub community and can be reviewed and eventually merged into the `main` version. This pull request and its associated changes will eventually be committed to the `main` branch and available in the next release. To submit a pull request:
|
||||
|
||||
1. Navigate to your repository on GitHub
|
||||
2. Click on the Pull Request button
|
||||
|
|
@ -287,7 +287,7 @@ This will automatically update your pull request with the latest code and restar
|
|||
|
||||
## 11. Delete your merged branch
|
||||
|
||||
Once your feature branch is merged into ``upstream master``, you can delete your remote branch via the ``Delete branch`` option in the PR and the local copy by running:
|
||||
Once your feature branch is merged into ``upstream main``, you can delete your remote branch via the ``Delete branch`` option in the PR and the local copy by running:
|
||||
|
||||
```bash
|
||||
$ git branch -d new-feature
|
||||
|
|
@ -301,5 +301,5 @@ $ git branch -d new-feature
|
|||
- Write new tests if needed. See "Testing with Continuous Integration"
|
||||
- Test the code using unittest. Running all tests takes a while, so feel free to only run the tests you think are needed based on your PR. CI will catch any failing tests.
|
||||
* In R, you can also run ``devtools:check()`` for carrying out a number of automated checks all at once, for code problems, documentation, testing, package structure, vignettes etc. This will take a few minutes to run.
|
||||
* Once you push your changes and make a PR, make sure you use an informative title which summarizes the changes you have made.
|
||||
* Once you push your changes and make a PR, make sure you use an informative title which summarizes the changes you have made.
|
||||
* If the PR addresses an issue, please reference it e.g. fixes #1234
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ subsections:
|
|||
|
||||
|
||||
|
||||
Prophet can make forecasts for time series with sub-daily observations by passing in a dataframe with timestamps in the `ds` column. The format of the timestamps should be YYYY-MM-DD HH:MM:SS - see the example csv [here](https://github.com/facebook/prophet/blob/master/examples/example_yosemite_temps.csv). When sub-daily data are used, daily seasonality will automatically be fit. Here we fit Prophet to data with 5-minute resolution (daily temperatures at Yosemite):
|
||||
Prophet can make forecasts for time series with sub-daily observations by passing in a dataframe with timestamps in the `ds` column. The format of the timestamps should be YYYY-MM-DD HH:MM:SS - see the example csv [here](https://github.com/facebook/prophet/blob/main/examples/example_yosemite_temps.csv). When sub-daily data are used, daily seasonality will automatically be fit. Here we fit Prophet to data with 5-minute resolution (daily temperatures at Yosemite):
|
||||
|
||||
|
||||
```R
|
||||
|
|
@ -38,8 +38,8 @@ future = m.make_future_dataframe(periods=300, freq='H')
|
|||
fcst = m.predict(future)
|
||||
fig = m.plot(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The daily seasonality will show up in the components plot:
|
||||
|
|
@ -53,8 +53,8 @@ prophet_plot_components(m, fcst)
|
|||
# Python
|
||||
fig = m.plot_components(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<a id="data-with-regular-gaps"> </a>
|
||||
|
|
@ -86,8 +86,8 @@ future = m.make_future_dataframe(periods=300, freq='H')
|
|||
fcst = m.predict(future)
|
||||
fig = m.plot(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The forecast seems quite poor, with much larger fluctuations in the future than were seen in the history. The issue here is that we have fit a daily cycle to a time series that only has data for part of the day (12a to 6a). The daily seasonality is thus unconstrained for the remainder of the day and is not estimated well. The solution is to only make predictions for the time windows for which there are historical data. Here, that means to limit the `future` dataframe to have times from 12a to 6a:
|
||||
|
|
@ -95,7 +95,7 @@ The forecast seems quite poor, with much larger fluctuations in the future than
|
|||
|
||||
```R
|
||||
# R
|
||||
future2 <- future %>%
|
||||
future2 <- future %>%
|
||||
filter(as.numeric(format(ds, "%H")) < 6)
|
||||
fcst <- predict(m, future2)
|
||||
plot(m, fcst)
|
||||
|
|
@ -107,8 +107,8 @@ future2 = future2[future2['ds'].dt.hour < 6]
|
|||
fcst = m.predict(future2)
|
||||
fig = m.plot(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The same principle applies to other datasets with regular gaps in the data. For example, if the history contains only weekdays, then predictions should only be made for weekdays since the weekly seasonality will not be well estimated for the weekends.
|
||||
|
|
@ -140,8 +140,8 @@ future = m.make_future_dataframe(periods=3652)
|
|||
fcst = m.predict(future)
|
||||
fig = m.plot(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
This is the same issue from above where the dataset has regular gaps. When we fit the yearly seasonality, it only has data for the first of each month and the seasonality components for the remaining days are unidentifiable and overfit. This can be clearly seen by doing MCMC to see uncertainty in the seasonality:
|
||||
|
|
@ -163,8 +163,8 @@ fig = m.plot_components(fcst)
|
|||
WARNING:pystan:Run again with max_treedepth larger than 10 to avoid saturation
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The seasonality has low uncertainty at the start of each month where there are data points, but has very high posterior variance in between. When fitting Prophet to monthly data, only make monthly forecasts, which can be done by passing the frequency into `make_future_dataframe`:
|
||||
|
|
@ -182,8 +182,8 @@ future = m.make_future_dataframe(periods=120, freq='MS')
|
|||
fcst = m.predict(future)
|
||||
fig = m.plot(fcst)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
In Python, the frequency can be anything from the pandas list of frequency strings here: https://pandas.pydata.org/pandas-docs/stable/user_guide/timeseries.html#timeseries-offset-aliases . Note that `MS` used here is month-start, meaning the data point is placed on the start of each month.
|
||||
|
|
@ -200,4 +200,3 @@ In monthly data, yearly seasonality can also be modeled with binary extra regres
|
|||
|
||||
|
||||
Holiday effects are applied to the particular date on which the holiday was specified. With data that has been aggregated to weekly or monthly frequency, holidays that don't fall on the particular date used in the data will be ignored: for example, a Monday holiday in a weekly time series where each data point is on a Sunday. To include holiday effects in the model, the holiday will need to be moved to the date in the history dataframe for which the effect is desired. Note that with weekly or monthly aggregated data, many holiday effects will be well-captured by the yearly seasonality, so added holidays may only be necessary for holidays that occur in different weeks throughout the time series.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,14 +15,14 @@ subsections:
|
|||
|
||||
|
||||
|
||||
Prophet follows the `sklearn` model API. We create an instance of the `Prophet` class and then call its `fit` and `predict` methods.
|
||||
Prophet follows the `sklearn` model API. We create an instance of the `Prophet` class and then call its `fit` and `predict` methods.
|
||||
|
||||
|
||||
The input to Prophet is always a 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 a timestamp. The `y` column must be numeric, and represents the measurement we wish to forecast.
|
||||
|
||||
|
||||
|
||||
As an example, let's look at a time series of the log daily page views for the Wikipedia page for [Peyton Manning](https://en.wikipedia.org/wiki/Peyton_Manning). We scraped this data using the [Wikipediatrend](https://cran.r-project.org/package=wikipediatrend) package in R. Peyton Manning provides a nice example because it illustrates some of Prophet's features, like multiple seasonality, changing growth rates, and the ability to model special days (such as Manning's playoff and superbowl appearances). The CSV is available [here](https://github.com/facebook/prophet/blob/master/examples/example_wp_log_peyton_manning.csv).
|
||||
As an example, let's look at a time series of the log daily page views for the Wikipedia page for [Peyton Manning](https://en.wikipedia.org/wiki/Peyton_Manning). We scraped this data using the [Wikipediatrend](https://cran.r-project.org/package=wikipediatrend) package in R. Peyton Manning provides a nice example because it illustrates some of Prophet's features, like multiple seasonality, changing growth rates, and the ability to model special days (such as Manning's playoff and superbowl appearances). The CSV is available [here](https://github.com/facebook/prophet/blob/main/examples/example_wp_log_peyton_manning.csv).
|
||||
|
||||
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ We fit the model by instantiating a new `Prophet` object. Any settings to the f
|
|||
m = Prophet()
|
||||
m.fit(df)
|
||||
```
|
||||
Predictions are then made on a dataframe with a column `ds` containing the dates for which a prediction is to be made. You can get a suitable dataframe that extends into the future a specified number of days using the helper method `Prophet.make_future_dataframe`. By default it will also include the dates from the history, so we will see the model fit as well.
|
||||
Predictions are then made on a dataframe with a column `ds` containing the dates for which a prediction is to be made. You can get a suitable dataframe that extends into the future a specified number of days using the helper method `Prophet.make_future_dataframe`. By default it will also include the dates from the history, so we will see the model fit as well.
|
||||
|
||||
|
||||
```python
|
||||
|
|
@ -247,8 +247,8 @@ You can plot the forecast by calling the `Prophet.plot` method and passing in yo
|
|||
# Python
|
||||
fig1 = m.plot(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If you want to see the forecast components, you can use the `Prophet.plot_components` method. By default you'll see the trend, yearly seasonality, and weekly seasonality of the time series. If you include holidays, you'll see those here, too.
|
||||
|
|
@ -258,8 +258,8 @@ If you want to see the forecast components, you can use the `Prophet.plot_compon
|
|||
# Python
|
||||
fig2 = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
An interactive figure of the forecast and components can be created with plotly. You will need to install plotly 4.0 or above separately, as it will not by default be installed with prophet. You will also need to install the `notebook` and `ipywidgets` packages.
|
||||
|
|
@ -292,12 +292,11 @@ In R, we use the normal model fitting API. We provide a `prophet` function that
|
|||
library(prophet)
|
||||
```
|
||||
R[write to console]: Loading required package: Rcpp
|
||||
|
||||
|
||||
R[write to console]: Loading required package: rlang
|
||||
|
||||
|
||||
|
||||
First we read in the data and create the outcome variable. As in the Python API, this is a dataframe with columns `ds` and `y`, containing the date and numeric value respectively. The ds column should be YYYY-MM-DD for a date, or YYYY-MM-DD HH:MM:SS for a timestamp. As above, we use here the log number of views to Peyton Manning's Wikipedia page, available [here](https://github.com/facebook/prophet/blob/master/examples/example_wp_log_peyton_manning.csv).
|
||||
First we read in the data and create the outcome variable. As in the Python API, this is a dataframe with columns `ds` and `y`, containing the date and numeric value respectively. The ds column should be YYYY-MM-DD for a date, or YYYY-MM-DD HH:MM:SS for a timestamp. As above, we use here the log number of views to Peyton Manning's Wikipedia page, available [here](https://github.com/facebook/prophet/blob/main/examples/example_wp_log_peyton_manning.csv).
|
||||
|
||||
|
||||
```R
|
||||
|
|
@ -352,8 +351,8 @@ You can use the generic `plot` function to plot the forecast, by passing in the
|
|||
# R
|
||||
plot(m, forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
You can use the `prophet_plot_components` function to see the forecast broken down into trend, weekly seasonality, and yearly seasonality.
|
||||
|
|
@ -363,8 +362,8 @@ You can use the `prophet_plot_components` function to see the forecast broken do
|
|||
# R
|
||||
prophet_plot_components(m, forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
An interactive plot of the forecast using Dygraphs can be made with the command `dyplot.prophet(m, forecast)`.
|
||||
|
|
@ -372,4 +371,3 @@ An interactive plot of the forecast using Dygraphs can be made with the command
|
|||
|
||||
|
||||
More details about the options available for each method are available in the docstrings, for example, via `?prophet` or `?fit.prophet`. This documentation is also available in the [reference manual](https://cran.r-project.org/web/packages/prophet/prophet.pdf) on CRAN.
|
||||
|
||||
|
|
|
|||
|
|
@ -99,8 +99,8 @@ The holiday effect can be seen in the `forecast` dataframe:
|
|||
|
||||
```R
|
||||
# R
|
||||
forecast %>%
|
||||
select(ds, playoff, superbowl) %>%
|
||||
forecast %>%
|
||||
select(ds, playoff, superbowl) %>%
|
||||
filter(abs(playoff + superbowl) > 0) %>%
|
||||
tail(10)
|
||||
```
|
||||
|
|
@ -213,8 +213,8 @@ prophet_plot_components(m, forecast)
|
|||
# Python
|
||||
fig = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Individual holidays can be plotted using the `plot_forecast_component` function (imported from `prophet.plot` in Python) like `plot_forecast_component(m, forecast, 'superbowl')` to plot just the superbowl holiday component.
|
||||
|
|
@ -248,14 +248,14 @@ You can see which holidays were included by looking at the `train_holiday_names`
|
|||
# R
|
||||
m$train.holiday.names
|
||||
```
|
||||
[1] "playoff" "superbowl"
|
||||
[3] "New Year's Day" "Martin Luther King Jr. Day"
|
||||
[5] "Washington's Birthday" "Memorial Day"
|
||||
[7] "Independence Day" "Labor Day"
|
||||
[9] "Columbus Day" "Veterans Day"
|
||||
[11] "Veterans Day (Observed)" "Thanksgiving"
|
||||
[1] "playoff" "superbowl"
|
||||
[3] "New Year's Day" "Martin Luther King Jr. Day"
|
||||
[5] "Washington's Birthday" "Memorial Day"
|
||||
[7] "Independence Day" "Labor Day"
|
||||
[9] "Columbus Day" "Veterans Day"
|
||||
[11] "Veterans Day (Observed)" "Thanksgiving"
|
||||
[13] "Christmas Day" "Independence Day (Observed)"
|
||||
[15] "Christmas Day (Observed)" "New Year's Day (Observed)"
|
||||
[15] "Christmas Day (Observed)" "New Year's Day (Observed)"
|
||||
|
||||
|
||||
```python
|
||||
|
|
@ -289,7 +289,7 @@ The holidays for each country are provided by the `holidays` package in Python.
|
|||
|
||||
|
||||
|
||||
In Python, most holidays are computed deterministically and so are available for any date range; a warning will be raised if dates fall outside the range supported by that country. In R, holiday dates are computed for 1995 through 2044 and stored in the package as `data-raw/generated_holidays.csv`. If a wider date range is needed, this script can be used to replace that file with a different date range: https://github.com/facebook/prophet/blob/master/python/scripts/generate_holidays_file.py.
|
||||
In Python, most holidays are computed deterministically and so are available for any date range; a warning will be raised if dates fall outside the range supported by that country. In R, holiday dates are computed for 1995 through 2044 and stored in the package as `data-raw/generated_holidays.csv`. If a wider date range is needed, this script can be used to replace that file with a different date range: https://github.com/facebook/prophet/blob/main/python/scripts/generate_holidays_file.py.
|
||||
|
||||
|
||||
|
||||
|
|
@ -306,8 +306,8 @@ prophet_plot_components(m, forecast)
|
|||
forecast = m.predict(future)
|
||||
fig = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<a id="fourier-order-for-seasonalities"> </a>
|
||||
|
|
@ -330,8 +330,8 @@ from prophet.plot import plot_yearly
|
|||
m = Prophet().fit(df)
|
||||
a = plot_yearly(m)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The default values are often appropriate, but they can be increased when the seasonality needs to fit higher-frequency changes, and generally be less smooth. The Fourier order can be specified for each built-in seasonality when instantiating the model, here it is increased to 20:
|
||||
|
|
@ -348,8 +348,8 @@ from prophet.plot import plot_yearly
|
|||
m = Prophet(yearly_seasonality=20).fit(df)
|
||||
a = plot_yearly(m)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Increasing the number of Fourier terms allows the seasonality to fit faster changing cycles, but can also lead to overfitting: N Fourier terms corresponds to 2N variables used for modeling the cycle
|
||||
|
|
@ -388,8 +388,8 @@ m.add_seasonality(name='monthly', period=30.5, fourier_order=5)
|
|||
forecast = m.fit(df).predict(future)
|
||||
fig = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<a id="seasonalities-that-depend-on-other-factors"> </a>
|
||||
|
|
@ -452,8 +452,8 @@ future['off_season'] = ~future['ds'].apply(is_nfl_season)
|
|||
forecast = m.fit(df).predict(future)
|
||||
fig = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Both of the seasonalities now show up in the components plots above. We can see that during the on-season when games are played every Sunday, there are large increases on Sunday and Monday that are completely absent during the off-season.
|
||||
|
|
@ -470,8 +470,8 @@ If you find that the holidays are overfitting, you can adjust their prior scale
|
|||
# R
|
||||
m <- prophet(df, holidays = holidays, holidays.prior.scale = 0.05)
|
||||
forecast <- predict(m, future)
|
||||
forecast %>%
|
||||
select(ds, playoff, superbowl) %>%
|
||||
forecast %>%
|
||||
select(ds, playoff, superbowl) %>%
|
||||
filter(abs(playoff + superbowl) > 0) %>%
|
||||
tail(10)
|
||||
```
|
||||
|
|
@ -640,8 +640,8 @@ future['nfl_sunday'] = future['ds'].apply(nfl_sunday)
|
|||
forecast = m.predict(future)
|
||||
fig = m.plot_components(forecast)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
NFL Sundays could also have been handled using the "holidays" interface described above, by creating a list of past and future NFL Sundays. The `add_regressor` function provides a more general interface for defining extra linear regressors, and in particular does not require that the regressor be a binary indicator. Another time series could be used as a regressor, although its future values would have to be known.
|
||||
|
|
@ -671,4 +671,3 @@ Extra regressors are put in the linear component of the model, so the underlying
|
|||
|
||||
|
||||
To extract the beta coefficients of the extra regressors, use the utility function `regressor_coefficients` (`from prophet.utilities import regressor_coefficients` in Python, `prophet::regressor_coefficients` in R) on the fitted model. The estimated beta coefficient for each regressor roughly represents the increase in prediction value for a unit increase in the regressor value (note that the coefficients returned are always on the scale of the original data). If `mcmc_samples` is specified, a credible interval for each coefficient is also returned, which can help identify whether each regressor is "statistically significant".
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
{% else %}
|
||||
{{ content }}
|
||||
|
||||
<p><a class="edit-page-link" href="https://github.com/{{ site.ghrepo }}/blob/master/docs/{{ page.path }}" target="_blank">Edit on GitHub</a></p>
|
||||
<p><a class="edit-page-link" href="https://github.com/{{ site.ghrepo }}/blob/main/docs/{{ page.path }}" target="_blank">Edit on GitHub</a></p>
|
||||
{% endif %}
|
||||
</article>
|
||||
{% include doc_paging.html %}
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue