EViews.com

Dear friends,

I am doing some experiments with Eviews SSpace object for estimation of trend/cycle of GDP, and I recently observed something at least intriguing for me: the order at which you specify @state equations do matter for the result of the ML estimation on this object!
I will paste in what follows a SSpace specification with correspondent results, and then the results using the same specification but exchanging the position of one of the @space lines:

============================
PARAM C(1) 0 c(2) 0
@SIGNAL Y = TREND + CYCLE
@STATE CYCLE = c(2)*CYCLE(-1) + [ENAME = E1, VAR = EXP(C(1))]
@STATE TREND = c(2)*TREND(-1) + TREND2(-1)
@STATE TREND2 = TREND2(-1) + TREND3(-1)
@STATE TREND3 = TREND3(-1) + [ENAME = E2, VAR = EXP(C(1))/1600]
---------------------------------------
Estimation Results for the above spec:
Sspace: HP_AR1
Method: Maximum likelihood (Marquardt)
Date: 12/26/11 Time: 18:47
Sample: 1960Q1 1968Q3
Included observations: 35
Convergence achieved after 17 iterations

Coefficient Std. Error z-Statistic Prob.

C(1) -10.13306 0.188344 -53.80094 0.0000
C(2) 0.500952 0.008582 58.36937 0.0000

Final State Root MSE z-Statistic Prob.

CYCLE -0.001621 0.006798 -0.238527 0.8115
TREND 6.582917 0.005671 1160.763 0.0000
TREND2 3.296792 0.003529 934.2164 0.0000
TREND3 0.005788 0.000523 11.07455 0.0000

Log likelihood 83.00840 Akaike info criterion -4.629052
Parameters 2 Schwarz criterion -4.540175
Diffuse priors 4 Hannan-Quinn criter. -4.598371
============================

Now the same specification, just pushing the first @state definition to the last row:
============================
PARAM C(1) 0 c(2) 0
@SIGNAL Y = TREND + CYCLE
@STATE TREND = c(2)*TREND(-1) + TREND2(-1)
@STATE TREND2 = TREND2(-1) +TREND3(-1)
@STATE TREND3 = TREND3(-1) + [ENAME = E2, VAR = EXP(C(1))/1600]
@STATE CYCLE = c(2)*CYCLE(-1) + [ENAME = E1, VAR = EXP(C(1))]
---------------------------------------
Estimation Results for the above spec:
Sspace: HP_AR1
Method: Maximum likelihood (Marquardt)
Date: 12/26/11 Time: 19:01
Sample: 1960Q1 1968Q3
Included observations: 35
Convergence achieved after 22 iterations

Coefficient Std. Error z-Statistic Prob.

C(1) -10.16572 0.209222 -48.58811 0.0000
C(2) 0.735655 0.102524 7.175430 0.0000

Final State Root MSE z-Statistic Prob.

TREND 6.582204 0.017612 373.7393 0.0000
TREND2 1.751350 0.003472 504.4536 0.0000
TREND3 0.002992 0.000514 5.819456 0.0000
CYCLE -0.002010 0.017462 -0.115089 0.9084

Log likelihood 86.90387 Akaike info criterion -4.851649
Parameters 2 Schwarz criterion -4.762772
Diffuse priors 4 Hannan-Quinn criter. -4.820969
============================

Let me call your attention to the estimates of the c(2) coef (in bold), which are very different, though the estimates are based on the same specification and data. Interestingly, using the Berndt-Hall-Hall-Hausman optimization algorithm the difference between estimates is not so pronounced. Using the Marquardt algorithm I tried to reduce the convergence criteria to 1e-24, but the discrepancies persist. Is this an algorithm drawback? Still, given that the specification and the data are the same, it looks more like a bug to me...

For those interested, I take this specification to represent a time series (structurally) decomposed into a trend that follows an ARIMA(1,2,0), and a cycle that follows an ARIMA(1,0,0), with the AR coef. to be estimated (c(2) in the SSpace), and the variances determined according to the standard HP filter.

If someone could help me to find an explanation, or suggestion of how to avoid such a sensitivity to the order of specification within SSpace objects, I would be very grateful.

Regards,
Jaqueson

The order in which you specify equations doesn't matter for the object per se, but it may matter for some specifications, as it does in any nonlinear system estimation.

The issue with state space models is that since they depend on the construction of observed variables, models may be very tenuously identified, at best, with many local roots. Thus, even more than other nonlinear specifications that you might estimate, one has to experiment with various starting values. In your case, with 35 observations, it does not surprise me that you are finding different roots with different starting values (note, that you might also like to tighten the convergence tolerance somewhat -- I usually use roughly 1e-6 for state space models as any tighter starts to run into limits of precision of the numeric derivatives)

That's a long way of saying that state space models will always be somewhat sensitive to the order of variables entering as it affects starting values (and possibly algorithms for performing matrix inversion). But this is a universal issue with system estimation that is not specific to state space estimation. The only thing you can do is to experiment with different starting values and other robustness checks...