Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rules of thumb for Fourier orders with weekly, monthly & yearly seasonalities #1213

Closed
cereusperuv opened this issue Nov 13, 2019 · 2 comments

Comments

@cereusperuv
Copy link

Thanks for an awesome package that I have so far used alot for both prediction and data exploration!

I have a question on Fourier orders when using several seasonalities in combination. The data I work with usually has an overall trend plus yearly, monthly and weekly seasonalities (even daily but I hardly ever model that time scale). I suspect it may be wise to limit the Fourier order of e.g. the monthly seasonality terms so that they do not overlap with the week season and start to correlate with those terms (same for yearly vs. monthly seasonalities). Is this something you have noticed while building & testing this package and if so, are there any rules of thumb to follow while allocating Fourier orders to the various included seasonalities?

Thanks in advance.

@bletham
Copy link
Contributor

bletham commented Jan 27, 2020

This isn't something that we've looked into in great detail. For yearly seasonality, the default of 10 means the highest-frequency component will have a period of 365/10 = 36.5 days. So increasing that would give the yearly seasonality a component with monthly frequency. But I wouldn't expect this to really cause any issue. Suppose we have yearly seasonality with Fourier order of 20; there would be only 1 component that has monthly seasonality (12). It would probably be a poor model of monthly seasonality by itself since it is a single sin/cos, and is missing the higher-frequency components that the monthly seasonality model has. In order for yearly seasonality to pick up the second component for monthly seasonality, it would have to have a Fourier order of 24; to get the third would be 48, etc. So basically I think it would require really high values of Fourier order before there would be any significant modeling conflict between the seasonalities. This is a hyperparameter that we usually have seen pretty limited sensitivity to - the instances where it has been too small it's usually been pretty clear from the visualization that there is a fast change in seasonality, so we just bump it up a bit and then it fits nicely. From a tuning point of view, I think 3-20 is a pretty expansive range, and I suspect that if there are such sharp changes in seasonality that require a Fourier order higher than 20 then there might be a better approach for modeling them. Hope that helps!

@cereusperuv
Copy link
Author

@bletham Thanks. Very enlightening answer. In my business setting there is a clear end-of-week effect. Applying the same sort of logic on monthly vs weekly season, it may then seem wise to restrict the number of monthly components to maximum 5 or something, else the monthly components might start picking up the end-of-week sales boost.

@bletham bletham closed this as completed Feb 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants