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

[pgg1309]

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]

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]

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]

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]

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 #62 but will take a bunch of work.

[pgg1309]

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]

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

[mitchelloharawild]

Closing as the misunderstanding seems resolved, and is now a duplicate of #62