"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/_docs/additional_topics.md" between
prophet-1.0.tar.gz and prophet-1.1.tar.gz

About: Prophet is a tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.

additional_topics.md  (prophet-1.0):additional_topics.md  (prophet-1.1)
skipping to change at line 13 skipping to change at line 13
docid: "additional_topics" docid: "additional_topics"
title: "Additional Topics" title: "Additional Topics"
permalink: /docs/additional_topics.html permalink: /docs/additional_topics.html
subsections: subsections:
- title: Saving models - title: Saving models
id: saving-models id: saving-models
- title: Flat trend and custom trends - title: Flat trend and custom trends
id: flat-trend-and-custom-trends id: flat-trend-and-custom-trends
- title: Updating fitted models - title: Updating fitted models
id: updating-fitted-models id: updating-fitted-models
- title: External references
id: external-references
--- ---
<a id="saving-models"> </a> <a id="saving-models"> </a>
### Saving models ### Saving models
It is possible to save fitted Prophet models so that they can be loaded and used later. It is possible to save fitted Prophet models so that they can be loaded and used later.
In R, this is done with `saveRDS` and `readRDS`: In R, this is done with `saveRDS` and `readRDS`:
```R ```R
# R # R
saveRDS(m, file="model.RDS") # Save model saveRDS(m, file="model.RDS") # Save model
m <- readRDS(file="model.RDS") # Load model m <- readRDS(file="model.RDS") # Load model
``` ```
In Python, models should not be saved with pickle; the Stan backend attached to the model object will not pickle well, and will produce issues under certain ver sions of Python. Instead, you should use the built-in serialization functions to serialize the model to json: In Python, models should not be saved with pickle; the Stan backend attached to the model object will not pickle well, and will produce issues under certain ver sions of Python. Instead, you should use the built-in serialization functions to serialize the model to json:
```python ```python
# Python # Python
import json
from prophet.serialize import model_to_json, model_from_json from prophet.serialize import model_to_json, model_from_json
with open('serialized_model.json', 'w') as fout: with open('serialized_model.json', 'w') as fout:
json.dump(model_to_json(m), fout) # Save model fout.write(model_to_json(m)) # Save model
with open('serialized_model.json', 'r') as fin: with open('serialized_model.json', 'r') as fin:
m = model_from_json(json.load(fin)) # Load model m = model_from_json(fin.read()) # Load model
``` ```
The json file will be portable across systems, and deserialization is backwards compatible with older versions of prophet. The json file will be portable across systems, and deserialization is backwards compatible with older versions of prophet.
<a id="flat-trend-and-custom-trends"> </a> <a id="flat-trend-and-custom-trends"> </a>
### Flat trend and custom trends ### Flat trend and custom trends
For time series that exhibit strong seasonality patterns rather than trend chang es, it may be useful to force the trend growth rate to be flat. This can be achi eved simply by passing `growth=flat` when creating the model: For time series that exhibit strong seasonality patterns rather than trend chang es, it may be useful to force the trend growth rate to be flat. This can be achi eved simply by passing `growth=flat` when creating the model:
```R ```R
# R # R
m <- prophet(df, growth='flat') m <- prophet(df, growth='flat')
``` ```
```python ```python
# Python # Python
m = Prophet(growth='flat') m = Prophet(growth='flat')
``` ```
Note that if this is used on a time series that doesn't have a constant trend, a ny trend will be fit with the noise term and so there will be high predictive un certainty in the forecast. Note that if this is used on a time series that doesn't have a constant trend, a ny trend will be fit with the noise term and so there will be high predictive un certainty in the forecast.
To use a trend besides these three built-in trend functions (piecewise linear, p iecewise logistic growth, and flat), you can download the source code from githu b, modify the trend function as desired in a local branch, and then install that local version. This PR provides a good illustration of what must be done to imp lement a custom trend (https://github.com/facebook/prophet/pull/1466/files), as does this one that implements a step function trend (https://github.com/facebook /prophet/pull/1794) and this one for a new trend in R (https://github.com/facebo ok/prophet/pull/1778). To use a trend besides these three built-in trend functions (piecewise linear, p iecewise logistic growth, and flat), you can download the source code from githu b, modify the trend function as desired in a local branch, and then install that local version. [This PR](https://github.com/facebook/prophet/pull/1466/files) p rovides a good illustration of what must be done to implement a custom trend, as does [this one](https://github.com/facebook/prophet/pull/1794) that implements a step function trend and [this one](https://github.com/facebook/prophet/pull/17 78) for a new trend in R.
<a id="updating-fitted-models"> </a> <a id="updating-fitted-models"> </a>
### Updating fitted models ### Updating fitted models
A common setting for forecasting is fitting models that need to be updated as ad ditional data come in. Prophet models can only be fit once, and a new model must be re-fit when new data become available. In most settings, model fitting is fa st enough that there isn't any issue with re-fitting from scratch. However, it i s possible to speed things up a little by warm-starting the fit from the model p arameters of the earlier model. This code example shows how this can be done in Python: A common setting for forecasting is fitting models that need to be updated as ad ditional data come in. Prophet models can only be fit once, and a new model must be re-fit when new data become available. In most settings, model fitting is fa st enough that there isn't any issue with re-fitting from scratch. However, it i s possible to speed things up a little by warm-starting the fit from the model p arameters of the earlier model. This code example shows how this can be done in Python:
```python ```python
# Python # Python
def stan_init(m): def stan_init(m):
skipping to change at line 103 skipping to change at line 104
%timeit m2 = Prophet().fit(df) # Adding the last day, fitting from scratch %timeit m2 = Prophet().fit(df) # Adding the last day, fitting from scratch
%timeit m2 = Prophet().fit(df, init=stan_init(m1)) # Adding the last day, warm- starting from m1 %timeit m2 = Prophet().fit(df, init=stan_init(m1)) # Adding the last day, warm- starting from m1
``` ```
1.33 s ± 55.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) 1.33 s ± 55.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
185 ms ± 4.46 ms per loop (mean ± std. dev. of 7 runs, 10 loops each) 185 ms ± 4.46 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
As can be seen, the parameters from the previous model are passed in to the fitt ing for the next with the kwarg `init`. In this case, model fitting was about 5x faster when using warm starting. The speedup will generally depend on how much the optimal model parameters have changed with the addition of the new data. As can be seen, the parameters from the previous model are passed in to the fitt ing for the next with the kwarg `init`. In this case, model fitting was about 5x faster when using warm starting. The speedup will generally depend on how much the optimal model parameters have changed with the addition of the new data.
There are few caveats that should be kept in mind when considering warm-starting . First, warm-starting may work well for small updates to the data (like the add ition of one day in the example above) but can be worse than fitting from scratc h if there are large changes to the data (i.e., a lot of days have been added). This is because when a large amount of history is added, the location of the cha ngepoints will be very different between the two models, and so the parameters f rom the previous model may actually produce a bad trend initialization. Second, as a detail, the number of changepoints need to be consistent from one model to the next or else an error will be raised because the changepoint prior parameter `delta` will be the wrong size. There are few caveats that should be kept in mind when considering warm-starting . First, warm-starting may work well for small updates to the data (like the add ition of one day in the example above) but can be worse than fitting from scratc h if there are large changes to the data (i.e., a lot of days have been added). This is because when a large amount of history is added, the location of the cha ngepoints will be very different between the two models, and so the parameters f rom the previous model may actually produce a bad trend initialization. Second, as a detail, the number of changepoints need to be consistent from one model to the next or else an error will be raised because the changepoint prior parameter `delta` will be the wrong size.
<a id="external-references"> </a>
### External references
These github repositories provide examples of building on top of Prophet in ways
that may be of broad interest:
* [forecastr](https://github.com/garethcull/forecastr): A web app that provides
a UI for Prophet.
* [NeuralProphet](https://github.com/ourownstory/neural_prophet): A Prophet-styl
e model implemented in pytorch, to be more adaptable and extensible.
 End of changes. 6 change blocks. 
4 lines changed or deleted 5 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)