Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
by facebook4 of 6 standards met
I'm using prophet 1.1.7 within RStudio 2025.05.0+496 with ggplot2 version 4.0.0. I believe Prophet uses ggplot2 but may be using an older version of ggpolot2. My use of prophet::performance_metrics() is working but the prophet::plot_cross_validation_metric() produces a TRUE/FALSE y-axis is not what I expected. I am expected a plot that looks similar to what the following code produces manually:
Repository: facebook/prophet. Description: Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth. Stars: 20039, Forks: 4647. Primary language: Python. Languages: Python (61.5%), R (36.7%), Stan (1.8%), Dockerfile (0%), Makefile (0%). License: MIT. Homepage: https://facebook.github.io/prophet Topics: forecasting, python, r. Latest release: v1.3.0 (1mo ago). Open PRs: 8, open issues: 453. Last activity: 1w ago. Community health: 75%. Top contributors: bletham, tcuongd, seanjtaylor, ryankarlos, dependabot[bot], WardBrian, baogorek, jorenham, seriousran, joseangel-sc and others.
Python
Last 12 weeks · 13 commits
This adds annotations for the entire public API, and validates the correctness using Pyrefly. With this, the type coverage of the public API (excluding tests) is now at almost 100%. The one exception is , but that will be resolved once https://github.com/facebook/prophet/pull/2717 is merged. This also adds the required and classifier to make sure that users will also be able to fully benefit from all of these static typing goodies. See https://typing.python.org/en/latest/spec/distributing.html#packaging-typed-libraries for the story behind . I realize that this is a pretty beefy PR, but for what it's worth, I wrote these all by hand, so there's no need to worry about slop :). But things like this are difficult to split up, because adding/changing an annotation in module B can also affect module A, and vice-versa. That way, splitting things up is likely to come with a lot of overhead of going back and forth, as well as loads of merge-conflicts. So in my experience it's a lot less painful to annotate everything all at once. This supersedes #2704.