Repository navigation
A new bug in VARIMA (fable package) #446
Description
I noticed the following bug in the VARIMA function:
library(fpp3)
google_stock <- gafa_stock |>
filter(Symbol == "GOOG", year(Date) >= 2015) |>
mutate(day = row_number()) |>
update_tsibble(index = day, regular = TRUE)
google_2015 <- google_stock |> filter(year(Date) == 2015)
google_2015 |>
model(VARIMA(vars(log(Open), log(High)) ~ pdq(d = 1, q = 0)))
# A mable: 1 x 2
# Key: Symbol [1]
Symbol `VARIMA(vars(log(Open), log(High)) ~ pdq(d = 1, q = 0))`
<chr> <model>
1 GOOG <VARIMA(1,1,1) w/ mean>
As you can see, the above VARIMA specification does not produce a VAR(p)=VARMA(p,0) in differences of logs as it should (since we set q=0), but a VARMA(p,1) in differences of logs .
Similarly,
google_2015 |>
model(VARIMA(vars(log(Open), log(High)) ~ pdq(p=0,d = 1)))
# A mable: 1 x 2
# Key: Symbol [1]
Symbol `VARIMA(vars(log(Open), log(High)) ~ pdq(p = 0, d = 1))`
<chr> <model>
1 GOOG <VARIMA(1,1,1) w/ mean>
With the ARIMA function that I checked I did not notice this issue.
I feel the need to mention that the fable package is simply excellent! Thank you very much for all your efforts!
Activity
mitchelloharawild commentedon May 15, 2026
Thanks for your kind words!
That's a strange bug, the provided specification should definitely take precedence over any hyperparameter selection.
mitchelloharawild commentedon May 15, 2026
The identification methods available didn't support specific limits on 1 parameter over another, so I've added identification by minimising an information criterion which should work in any circumstances. Note that identification of multivariate VARIMA models is tricky, so if you don't need to constrain
porqyou might get more consistent results.Add ic_search identification for VARIMA