Re: [Gretl-devel] arima, re-,re-.....revisited

loglikelihood than x13as x13as use absolutely different method: iterative GLS https://pdfs.semanticscholar.org/77a0/3722ccff2226737ae78903d6005bb0f7549... If substarct calling API time it can be ~100 times more fast (it gives 3 sec with the same model) R variant is essentially the same: exact lik. via Kalman in normal situations as with (bjg) arima 0 1 1; 0 1 1; lg it is very similar in time and results and loglik But when number of (S)MA terms increase something going on with the native arima Also I attach my hansl code which makes safe inits: It does exactly nothing in the situations when the current default works and does something when it fails Oleh 21 лютого 2018, 17:25:29, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote: Thanks for pointing this out. The intended behavior of "arma" is that we fall back to OPG for the covariance matrix if computation of the Hessian fails -- unless the --hessian option is given, in which case an error is flagged if the request cannot be met. This facility got broken at some point, but it's now reinstated in git. Speed: We're aware that our exact ML estimation of complex ARIMA models via the Kalman filter is slow compared to some other software. This is something we're looking into. One point to note is that our implementation arguably offers "surplus precision" as it stands. For the specification above, for example, gretl gets a somewhat greater loglikelihood than x13as. (I haven't yet figured out how to get R's arima() to estimate this model.) Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel