On Mon, 26 Mar 2012, Daniel Bencik wrote: Well, the first thing I see is that your parameter "gc" is very very small and at "convergence" the corresponding gradient is not even close to zero. This, if I may, is the consequence of a poor modelling choice, since "4.39767E-07" for a parameter when you use numerical derivatives is definitely asking for trouble and it's a consequence of the scaling you chose for your dependent variable: try multiplying it by, say, 100 or 1000 and see what happens. When using numerical derivatives it's always a good idea to parametrise your model such that the order of magnitude of your estimates is as close to 1 as possible. Moreover, the output from eviews shows quite clearly that you have two pairs of common roots in your arma specification. What this means in practice is that with your data an arma(2,1) model is indentifiable; anything over that is going to display a loglikelihood function that is virtually flat in one or more directions (4 in your case). The consequences of the above are: 1) from a numerical point of view, your function is very, very flat for a large range of values. Since machine precision is limited anyway, you'll probably end on a "maximum" which turns out to be such out of machine-precision noise and little else. 2) From a statistical viewpoint, you have a model for whch no sensible estimator of the covariance matrix of the parameters exists (because of course if the loglikelihood is perfectly flat in at least one direction both the Hessian and the OPG are singular). In a finite-sample, finite-precision world, whatever standard errors you get from your algorithm is, again, machine-precision noise (also known as "rubbish") Finally, our algorithm does not include, as probably Eviews' does, some form of provision for what to do in the case when the MA polynomial has roots inside the unit circle (or whose absolute values smaller than one, if you prefer). So you end up with an estimate of the coefficients for the MA polynomial whose inverse roots are -1.2736 -0.40100 + 0.93150i -0.40100 - 0.93150i 0.63538 + 0.36511i 0.63538 - 0.36511i Which clearly don't match what eviews gives you, but most importantly the last conjugate pair is smugly inside the unit circle (and the first one is dangerously close): so in practice your MA representation is not invertible. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti

On Mon, 26 Mar 2012, Riccardo (Jack) Lucchetti wrote: Ooof, I really should read my own messages before sending them. These are the _roots_, not the inverse roots. However, my point still stands (the MA polynomial is nonivertible). To make amends, I'll include a short hansl script that someone may find useful/instructive/fun to look at <hansl> set echo off set messages off #estimated MA coefficients c = {-0.804878, 0.0506545, 0.180421, 0.563758, -0.703441} matrix T = c | (I(4) ~ 0) l = eigengen(T) il = cdiv(ones(5,1), l) m = sqrt(sumr(l.^2)) printf " Roots Inverse Roots Modulus\n\n" loop i=1..rows(l) --quiet scalar x = il[i,2] if x>0 printf "%9.6f + %9.6fi,", il[i,1], x elif x<0 printf "%9.6f - %9.6fi,", il[i,1], abs(x) else printf "%9.6f ,", il[i,1] endif scalar x = l[i,2] if x>0 printf " %9.6f + %9.6fi", l[i,1], x elif x<0 printf " %9.6f - %9.6fi", l[i,1], abs(x) else printf " %9.6f ", l[i,1] endif printf ", %9.6f\n", m[i] endloop </hansl> Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti

On Mon, 26 Mar 2012, Daniel Bencik wrote: Thanks for posting this info. If we're to check the results, however, we need access to the dataset you're using. Allin Cottrell