prophet
prophet copied to clipboard
facebook
New parameter added in order to replace negative predictions with 0
Sometimes, data series contain many values close to zero but are not expected to fall below zero. For example, a data frame with response times will likely have many near-zero values. In such cases, Prophet may produce yhat_lower or trend_lower metric values that are negative.
To address this issue, I have implemented a flag that sets trend, yhat, yhat lower and yhat upper values to zero in the future data frame. This flag can be configured when defining the model.
Hi @mrtergl!
Thank you for your pull request and welcome to our community.
Action Required
In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.
Process
In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.
Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.
If you have received this in error or have any questions, please contact us at [email protected]. Thanks!
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!
I think this pull request is useful.
I am currently using Prophet for various purposes. One of them is to predict traffic trends/detect anomalies.
I currently use it as a code to replace negative values with 0 in the post-processing process.
Because even if I do not train Prophet with values less than 0, there were cases where the prediction result was predicted as a negative number less than 0.
So I personally think this suggestion can be useful.
Hi @mrtergl!
Thanks for your contribution! I also agree that this is a fairly simple feature that gets often asked, so why not implement it. While reviewing the code I got one question. I am quite new to forecasting and even programming in Python, so please forgive me if the answer is obvious.
It seems that on line 1460 in file python/prophet/forecaster.py you clip all seasonality components' values to zero. Is it correct to do that? The effect of seasonality may be negative even if predicted y cannot be below zero, for example, sales of winter products cannot go negative but seasonality for summer months can.
Thanks in advance for your reply!
Hi @HumptyHans, Thank you for noticing, you are right about seasonality values being able to go below zero. I removed the part and tested it.
Hey @mrtergl, Thanks for making changes! But without seasonality clipping, the resulting value can still go below zero. Something needs to be done with 'additive_terms'. The easiest suggestion is to ensure that if it is negative, its absolute value doesn't exceed the trend value. I’m just not sure if it’s the correct approach from a statistical perspective.
Hi @HumptyHans ,
I'm not sure I understand you well because of my lack of knowledge in the statistical area. From what I understood, seasonality values such as 'additive_terms' can be negative while the prediction stays positive. I made some refactoring on the code and I hope I got the right result for all cases without negative predictions.
With all seasonalities included, here is the result you will get if you set negative_prediction_values to false.
As you can see seasonalities have both negative and positive values while prediction has always been positive
Hey @mrtergl I see that your last commit fixes exactly what I meant. Basically, the whole PR could have been reduced to these two lines:
if not self.negative_prediction_values:
df2['yhat'] = df2['yhat'].clip(lower=0)
Hi @HumptyHans ,
We should be able to make trend, yhat upper and yhat lower predictions positive while the flag negative_prediction_values is set to false. So the code you provided will be insufficient.
But I removed the part where I clipped seasonalities' lower and upper values. So that, all seasonality predictions (including upper and lower values) can be negative even if the metric is non-negative (such as count, latency).
Hi @tcuongd,
Is there anything I should do before merge my pull request to main? Is this all okay to be merged ?
Sorry for the delay! Unfortunately I'm not sure I would put this in the package. What is the benefit of this versus the user doing future_df.clip(min=0)?
The reason being, it's not completely accurate. "trend" is meant to represent the mean of the prediction distribution. So technically we should be clipping the prediction distribution, then computing trend and lower / upper.
So if this approach is an approximation, and it's a one-liner for the end user, I'd rather not have it as core functionality.
Hi @tcuongd,
Thanks for the feedback. I understand your point about this being an approximation and easily achievable via future_df.clip(min=0). However, I think it will be better to have it as a centralized flag, especially for users who may not be aware of the implications or who repeatedly encounter the same pattern.
The reason being, it's not completely accurate. "trend" is meant to represent the mean of the prediction distribution. So technically we should be clipping the prediction distribution, then computing trend and lower / upper.
That makes sense — and I agree that ideally we’d clip the distribution itself before computing the forecast components. But what I see from the issues and what I experienced so far while using Prophet is, many users are concerned with avoiding negative values in outputs like yhat, trend, or intervals, especially when modeling quantities that logically can’t go below zero . That’s why I thought it would be useful, even if it only affects the output values and not the internal computation.