As per my understanding period of seasonality will depend on data aggregation. For example, if data is aggregated at weekly level and there is yearly seasonality. So, period in this case would be 52 or 53, and not 365.5, as week 1 of Jan 2014 will be similar to week 1 of Jan 2015, and as data is weekly aggregated there are 52 or 53 points between the two similar period.
This could be cause of concern as using period of 52 and period of 365.5 gives different seasonality curve. See attached images
Period 365.5
Period 52
Even if seasonality with 365.5 seems to be smoother, but the one created with 52 seems better.
Please let me know, if my understanding is correct!
datafool
All 3 comments
In principle this is correct, it'd be better for weekly data to do a Fourier decomposition specific to weekly data, which would have then a period of 52.
However Prophet (currently) represents everything as daily data. So even if you give it weekly aggregates, they will be identified using a particular day (e.g. first day of week) and basically Prophet will treat it as a single-day observation on that day. This means that if you specify a period of 52, it would be of 52 days (not weeks) which wouldn't work.
For the purposes of seasonality, I don't think it is awful to treat each weekly aggregate as a daily observation. The first day of week 1 of 2016 was Jan 3, and the first day of week 1 2017 was Jan 1. The yearly seasonality estimate is necessarily smooth because it is the first 10 terms of the Fourier decomposition, which means that the yearly seasonality estimate for Jan 1 and Jan 3 will be similar, and thus so will be for week 1 2015 and week 1 2016.
This is a similar issue as that illustrated for monthly data in the documentation (https://facebookincubator.github.io/prophet/docs/non-daily_data.html). The data there look like '1992-01-01', '1992-02-01', .... The yearly seasonality uses the full period of 365, not 12, and so it produces bad estimates for the within-month dates. However if you forecast forward just on the first of each month, you get something reasonable. Weekly data would be a similar situation, although I think it would be nicer than with monthly data since there are more data per year and so the seasonality is more constrained.
It would be good in the future to have a way of specifying data as weekly or monthly and then producing the appropriate seasonality periods. We'll just have to think carefully about what we want to do with holidays in this case. This is related to #29, and I think there is a lot of overlap between what is required for #29 and for this.
bletham
on 16 Mar 2017
Adding this an enhancement. We can think about getting this into 0.2 or the 0.3 release.
seanjtaylor
on 20 Mar 2017
Adding this as an enhancement will be awesome. As we have an agreement on this, we can close this issue!
datafool
on 23 Mar 2017
Related issues
andrew-pollock
·
3Comments
rev3ks
·
3Comments
Earththing
·
3Comments
xiaoyaoyang
·
3Comments
annabednarska
·
3Comments
Most helpful comment
In principle this is correct, it'd be better for weekly data to do a Fourier decomposition specific to weekly data, which would have then a period of 52.
However Prophet (currently) represents everything as daily data. So even if you give it weekly aggregates, they will be identified using a particular day (e.g. first day of week) and basically Prophet will treat it as a single-day observation on that day. This means that if you specify a period of 52, it would be of 52 days (not weeks) which wouldn't work.
For the purposes of seasonality, I don't think it is awful to treat each weekly aggregate as a daily observation. The first day of week 1 of 2016 was Jan 3, and the first day of week 1 2017 was Jan 1. The yearly seasonality estimate is necessarily smooth because it is the first 10 terms of the Fourier decomposition, which means that the yearly seasonality estimate for Jan 1 and Jan 3 will be similar, and thus so will be for week 1 2015 and week 1 2016.
This is a similar issue as that illustrated for monthly data in the documentation (https://facebookincubator.github.io/prophet/docs/non-daily_data.html). The data there look like
'1992-01-01', '1992-02-01', .... The yearly seasonality uses the full period of 365, not 12, and so it produces bad estimates for the within-month dates. However if you forecast forward just on the first of each month, you get something reasonable. Weekly data would be a similar situation, although I think it would be nicer than with monthly data since there are more data per year and so the seasonality is more constrained.It would be good in the future to have a way of specifying data as weekly or monthly and then producing the appropriate seasonality periods. We'll just have to think carefully about what we want to do with holidays in this case. This is related to #29, and I think there is a lot of overlap between what is required for #29 and for this.