Suppose I have a tsibble ts with columns Predictor and Predicted. Then stats::ccf(ts$Predictor, ts$Predicted) measures the correlation of lags of Predictor compared to Predicted. But feasts::CCF(ts$Predictor, ts$Predicted) measures the correlation of lags of Predicted compared to Predictor. This is a new behaviour as of feasts 0.3, previously the two calls were equivalent. So far as I can see the new behaviour is the correct behaviour (#144), but it silently broke some of our scripts on upgrading. Of course this is alpha software and we should expect breakages like this, but it would be very helpful if either
a note is added to the documentation explicitly saying that the two variables are in the opposite order to the base function: currently the only place you can see is that in the function signature there is y, x not x, y (the transposition of two letters in this one place is very easy to miss, especially when many of the code examples in various places online were put up before this change), and in the details section it is written that
"The functions improve the... stats::ccf() functions. The main differences are that ACF does not plot the exact correlation at lag 0 when type=="correlation" and the horizontal axes show lags in time units rather than seasonal units."
i.e. there is no mention of the rather major difference that the function parameters are reversed, and it sounds like CCF is a drop-in replacement for ccf!
or, a warning is added if the user is calling the function without specifying x or y specifically: so ts %>% CCF(Predictor, Predicted) would raise a warning and ts %>% CCF(x=Predictor, y=Predicted) would not. This would provide a hint that maybe there is something going on that the user should check.
Thanks for your very useful software, in any case.
Suppose I have a tsibble
tswith columnsPredictorandPredicted. Thenstats::ccf(ts$Predictor, ts$Predicted)measures the correlation of lags ofPredictorcompared toPredicted. Butfeasts::CCF(ts$Predictor, ts$Predicted)measures the correlation of lags ofPredictedcompared toPredictor. This is a new behaviour as of feasts 0.3, previously the two calls were equivalent. So far as I can see the new behaviour is the correct behaviour (#144), but it silently broke some of our scripts on upgrading. Of course this is alpha software and we should expect breakages like this, but it would be very helpful if eithera note is added to the documentation explicitly saying that the two variables are in the opposite order to the base function: currently the only place you can see is that in the function signature there is
y, xnotx, y(the transposition of two letters in this one place is very easy to miss, especially when many of the code examples in various places online were put up before this change), and in the details section it is written that"The functions improve the...
stats::ccf()functions. The main differences are that ACF does not plot the exact correlation at lag 0 when type=="correlation" and the horizontal axes show lags in time units rather than seasonal units."i.e. there is no mention of the rather major difference that the function parameters are reversed, and it sounds like
CCFis a drop-in replacement forccf!or, a warning is added if the user is calling the function without specifying
xoryspecifically: sots %>% CCF(Predictor, Predicted)would raise a warning andts %>% CCF(x=Predictor, y=Predicted)would not. This would provide a hint that maybe there is something going on that the user should check.Thanks for your very useful software, in any case.