Dynare forums

Dear all,

I get the following message (many times) during ML estimation with Dynare 3 (snapshot version). Does anyone know what it means:

DiffuseLiklihood3 :: T does influence the rank of Pinf!


Should I trust the estimates?

Thank you! Jean-Paul

Program attached.

This comes from a problem with the initialization of the diffuse Kalman filter with cointegrated systems. We made some progress in version 4 and, in the case of this model, I can't replicate the problem in v4, so I guess the procedure currently in version 4 is correct for this model.

We are currently working on a more general solution.

By the way, I don't understand why you feel necessary to introduce x rahter than writing simply

Code: Select all

pty = x1(-1)+bet*(y-y(-1))


Best

Michel

You are absolutely right, I could have just written the equation like that...

Regarding the error message, I had seen that it does not appear with version 4. I posted the question because by comparing the estimates v3 and v4 give, the are roughly the same, and therefore it seems that I can still trust the estimates of v3 even if the error message appears... do you think I am right?

By the way, I ask the question because I know that some of my programs won't run in version 4... see for instance the attached sample code. The problem I have is that I have to solve for the state space representation myself in the 'model' section. The reason is that I am handling a non-standard model where the information set of the agents is restricted (they do not observe some of the shocks, but receive a signal about them, and then they do Kalman filtering, as in Lorenzoni 2006). Therefore, Dynare's procedure would not give me the state-space representation we want.

I have thought hard about how to "trick" Dynare to compute the state-space representation we want, but so far it seems impossible. So, I have to solve for it myself and give complicated parameter transformations in the 'model' section. The code I attached is an example where I handle a matrix using the '#' option, using iterations, and then try to estimate the deep parameters. It works fine, but only with version 3 (I think I read somewhere that you are still working on parameter transformations in v4).

Michel, if you have a couple of minutes, could you please point to potential issues I could run with this type of codes? Your help will be highly appreciated.

This is a neat trick. Maybe it will work in version 4 in the future, but we don't plan to allow explicitely for matrices in the future.

However, the procedure is inefficient, because the Kalman filter is ran twice for one value of the parameters when it should be possible to have a single loop.

As we are moving towards handling estimation of learning models, we may be able to provide a more efficient approach, but it isn't for the near future.

Best

Michel

Thanks