Suppose there is a bivariate VARMA(1,12), where the MA coefficient matrices are all zero at lags 1-11, and the lag 12 MA coefficient matrix is (0.9874~-0.0509)|(0.0471~1.0002). One can easily check that such a process should be invertible, as all the roots of the MA polynomial are outside the unit circle:
Yet, when calling ''
varmall'', it returns with error:
"VARMARES ERROR: model not invertible".
I was trying to debug, but unfortunately, the part ''
dllcall varmadll'' is not debuggable in GAUSS 13. It appears that ''
varmadll'' was simply imported from some other code written in either C or Fortran or Matlab.
The source of the code for varmall is in varmaml.src in the GAUSS Run-Time Library:
Remarks: varmadll is adapted from code developed by Jose Alberto
Mauricio of the Universidad Complutense de Madrid. It was published
as Algorithm AS311 in Applied Statistics. Also described in "Exact
maximum likelihood estimation of stationary vector ARMA models, JASA,
varmall expects the MA matrix in reverse order of yours. Thus
And it's not outside the unit circle and thus not invertible.
The MA polynomial is I-A1*z-A2*z^2-...-A12*z^12. So as per the documentation of ''
polymroot", one should use "
abs(polymroot(A12|zeros((q-1)*k,k)|eye(k)))" to check the roots to be outside of the unit circle or not, right?
Think about the simple univariate MA(1) with the MA coefficient 0.5. "
abs(polymroot(0.5|1))" gives a value of 2>1 and the process is invertible. And of course "
abs(polymroot(1|0.5))" gives 0.5.
Am I missing something here? Are you suggesting that one should put
theta_q|...|theta_1 as the input "
theta" to use "
varmall"? But this seems odd.
Ok, good point. I hadn't read the doc on polymroot. Roots are computed in several GAUSS Applications, TSMT, FANMT, e.g., which all use the conventional order for the MA coefficients, nor require the one, or identity matrix, in the list. I ran your MA coefficients in one of those procedures and it confirmed your result. I believe the problem is occurring in the varmadll. The roots are very close to being one, and I suspect there's a loss of precision in that routine sufficient to cause the varma calculation to fail. A twelfth order moving average is an increased level of difficulty. If your time series is reasonably large, you should be able to use the conditional method for computing the likelihood. In the meantime, we'll take a look at the source code for the varmadll.