A new bug in VARIMA (fable package)

[nickcox896]

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!

[mitchelloharawild]

Thanks for your kind words!

That's a strange bug, the provided specification should definitely take precedence over any hyperparameter selection.

[mitchelloharawild]

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 p or q you might get more consistent results.