Priors in SSpace

[gargajo]

Hiya

Just ran into what I think is a bug, perhaps not, but here's the case. Upon estimating a SS model programatically, such as

model.append @signal ...
model.append @state S1 ...
model.append @state S2 ... [for all states defined in the model]
model.append @mprior mpriorspec
model.append @vprior vpriorspec

where mpriorspec and vpriorspec are defined before (outside) the above block of code (structure of both priors adequately defined by checking the relevant system matrices), then runs

model.ml

apparently without glitch but upon calling

model.makestates(opts)

it crashes by saying "estimates are not valid". Two things here: if the priors were improperly specified to begin with (badly conformed, for example) with, the estimation (ML) step would crash. It seemingly does not as I can see by the status bar progress, when in fact it has blown-up. Otherwise, the makestates option would run without a problem. The question here is why it seemingly iterates through the ML step without throwing a hiss. I have narrowed the problem to the VPRIOR matrix.

Did a run where I removed my VPRIOR (assumed it diffuse) and the model converges. Checked the structure of the resulting VCOV matrix (which has a block structure, as I'm modeling SUTSE) to my specified VPRIOR and there are no differences apart from the fact that I set-up the VPRIOR as a diagonal matrix.

Any ideas? It might be that eviews cannot handle a SUTSE properly in terms of variances priors handling (estimates fine otherwise) but in principle I see no reason why not.

Thanks a lot.

Luc

[EViews Glenn]

Can you post your workfile or send it to support@eviews.com?

[gargajo]

Hiya Glenn

Unfortunately cannot, as it contains confidential information but might try to mock something up. Either way, let me condense the issue.

Assume you have a SUTSE design with N blocks of dimension K, so N denotes the N components (N-1 states and the measurement equation) in the system for which there are K possible equations. For example, Y might be a vector of K measurements which are stacked together, and for each measurement you specify N-1 state equations describing its dynamics, with suitable covariance restrictions tying-up the system. A dynamic factor model is one potential example.

Therefore, the system VCOV would be block diagonal of dimension N*K with the N-1 state VCOV first and the measurement equation VCOV last. The blocks are obviously of dimension K and any off-diagonal elements pick-up the covariance restrictions on the relevant N-th component.

A simple way to impose priors is to build two vectors: one which serves as indicator vector with the prior variances [v(1) v(2) ... v(N)] and a vector of K ones, leading to

diag(kronecker([v(1) ... v(N)],ones[K])) or equivalently kronecker(diag([v(1) .. v(N)],ones[K])

the [v(1) ... v(N)] vector acting as an indicator matrix in the sense that if the design involves a particular state where no disturbance is specified (a pure decomposition) then it becomes [v(1) v(2) 0 v(4) ... v(N)] where in this case, the N = 3 block of K state (or signal) equations have no disturbance component. This would deliver the required N*K by N*K priors matrix with the variances for the N relevant components alongside the main diagonal, or a 0 otherwise. It is clear we initialise the system by imposing equal variances within each of the N blocks [but not necessarily across, no reason why v(1) <> v(2)].

Simplest example is taking the familiar local linear trend specification

y[t] = mu[t]+e[t] with e[t] ~ N(0,var(e[t]))
mu[t+1] = mu[t] sl[t]+v[t] with v[t] ~ N(0,var(v[t]))
sl[t+1] = sl[t]+n[t] with n[t] ~ N(0,var(n[t]))

and imposing var(v[t]) = 0. This could be extended to k state equations mu[K,t] meaning the block of K variances (in this case for N=1 of 3 as mu[t+1] is at the top) become 0.

That is the matrix placed as VPRIOR. Then ML estimation proceeds and if all goes well (meaning: the system is properly identified) it will converge to a stable solution. In my case it seemingly does after 30-something iterations, in general. At that stage it is where if you want to pick-up any output (the states, for example) it comes out with a "SS estimates are not valid" message. But it makes no sense; by then the system would have (one assumes) converged and if so, the resulting VCOV matrix would be proper and that would be the one used to compute the states.

Counterfactual is estimating the SAME system without imposing priors on the VCOV, and again, it converges in about the same number of iterations; everything you want from there using this route proceeds smoothly.

Two possibilities: that the system has indeed SILENTLY not converged (in such case there are two options: singularity or having reached the max number of iterations without solving) but if so the SS object would (should?) pop-up with a message BEFORE attempting to solve for any of the system equations. Perhaps when done programatically that's not the case?

Now a catch. If I estimate the system with NO vpriors to start with, save the resulting VCOV matrix and use it as prior and re-run, it blows-up with the same "estimates not valid" message (even if I use as other starting values those obtained upon convergence, which would mean the whole thing should solve in 1 iteration only).

Views appreciated.

Thanks

Luc

[gargajo]

Bump. Anyone..?

[EViews Glenn]

Was hoping you could mock something up as trying to replicate this on the basis of your description is proving to be difficult.

[gargajo]

Hiya

Will try find time to mock it up and send a WF1 file across.

Thanks!