search

tidyverts / feasts

Feature Extraction And Statistics for Time Series
https://feasts.tidyverts.org/
291 stars 23 forks source link

STL decomposition: odd behavior when `season(period = 1)` #146

Closed pgg1309 closed 2 years ago

pgg1309 commented 2 years ago

Hello,

I was trying to change the degree of smoothness of the trend in an STL decomposition with no seasonal period.

Below the codes: dcmp <- aus_production %>% model(STL(Beer ~ trend(window = 3) + season(period = 1))) components(dcmp) %>% autoplot()

If I change to trend(window = 33) or any other number, there is no change in the output.

Is this the expected behavior ? Shouldn't this result in different trend smoothness ?

robjhyndman commented 2 years ago

season(period = 1) should give an error because you can't have seasonality with period 1. For some reason, rather than giving an error, it seems to be ignoring the argument for trend()

pgg1309 commented 2 years ago

season(period = 1) should give an error because you can't have seasonality with period 1. For some reason, rather than giving an error, it seems to be ignoring the argument for trend()

But isn't this an option used in your book to detect outliers?

I got the idea to use season(period = 1) from https://otexts.com/fpp3/missing-outliers.html but I was trying to be a bit more flexible on the 'trend'.

robjhyndman commented 2 years ago

Hmm. Yes, I'd forgotten that -- we do need a way to fit a non-seasonal STL when there would otherwise be a seasonal component. Setting period=1 was my hack to force that to occur. Maybe would be more transparent to have some other specification.

In any case, the trend() argument is being ignored in this situation. So that needs fixing.

mitchelloharawild commented 2 years ago

This is because stats::stl() only works for seasonal series, and we fall back to stats::supsmu() for non-seasonal cases. Removing this (bad) functionality would be too much of a breaking change, as many users use STL in non-seasonal applications. Adding a warning wouldn't be a bad idea.

The long term solution is to re-implement STL to not use stats::supsmu(), and instead allow for more flexible specification of the stl model. This change is described in https://github.com/tidyverts/feasts/issues/62 but will take a bunch of work.

pgg1309 commented 2 years ago

I saw the fall back to stats::supsmu() and tried to use the parameter bass to adjust the smoothness of the trend. But it also did not work. I am not sure, though, whether I did it the right way. I assumed there would be a ... parameter at the end of the STL() call and therefore tried to add STL(Beer ~ season(period = 1), bass = 5) but it failed to work.

mitchelloharawild commented 2 years ago

... isn't passed through to stats::supsmu(), it is passed to stats::stl() instead.

mitchelloharawild commented 2 years ago

Closing as the misunderstanding seems resolved, and is now a duplicate of https://github.com/tidyverts/feasts/issues/62