Dear all,
In ML estimation, I get different estimates for the standard errors of my model depending on whether I introduce the StdErrors in the “shocks” section of the model, or alternatively I normalize these to 1, and put the StdErr parameter in front of the shocks, directly in the ‘model’ section. In some cases estimation does not work, in others it does.
Does anybody know why this happens? In principle, it seems that where the parameter is introduced should not change the results.
I have attached the code.
Best regards,
Jean-Paul
model1.mod (854 Bytes)
Hi Jean-Paul,
you can’t estimate a parameter used in a shocks statement, because the shocks statement is evaluated only once and not for every parameter sets used during the estimation procedure.
If you want to estimate the std err of the shock, you need to use the stderr keyword in the estimated_params block, but this option isn’t possible in your case, because you would loose the restriction according the which the standard error is also a parameter in other equations of the model.
Best
Michel
Hi Michael,
Thank you very much for your reply. I was starting to get desperate with this 
I am not sure I understood your answer correctly, I probably did not. Are you saying that there is no way Dynare can estimate my model? From simulations/estimations it looks like it would work.
For a simpler example, please have a look at the attached code, where I have two simple orthogonal processes. In the second one, I put a parameter in front of the shock (the standard error) and normalize the shock’s stderr in the ‘shocks’ section. Then I use the same parameter in the first equation. When I allow the program to observe the first variable, it estimates the parameter correctly. Also when it observes the second variable, but for the same dataset, the estimate is slightly different, suggesting that estimation took place indeed differently. When I allow the program to observe both variables, I get a third estimate, inbetween the first two, as if it had taken the information from both equations into account…
Do you think I am wrong? If yes, why? And if you think that everything is working as I think in my code, do you think I could encounter problems in more complicated models of the same type (that I am planning to estimate…)?
Anyway, thanks again, and congratulations for providing us with such a fantastic tool.
Regards,
Jean-Paul
expe1.mod (502 Bytes)
Sorry, this wasn’t clear. Your last *.mod file is correct:
var x y;
varexo u1 u2;
parameters rhox rhoy sig_u2;
rhox = .8;
rhoy = .95;
sig_u2 = .02;
model;
x = 10*sig_u2*x(-1) + u1;
y = rhoy*y(-1) + sig_u2*u2;
end;
shocks;
var u1; stderr 0.01;
var u2; stderr 1;
end;
estimated_params;
sig_u2, .01;
end;
varobs x;
estimation(datafile=expdata);
What you can’t do is
var x y;
varexo u1 u2;
parameters rhox rhoy sig_u2;
rhox = .8;
rhoy = .95;
sig_u2 = .02;
model;
x = 10*sig_u2*x(-1) + u1;
y = rhoy*y(-1) + u2;
end;
shocks;
var u1; stderr 0.01;
var u2; stderr sig_u2;
end;
estimated_params;
sig_u2, .01;
end;
varobs x;
estimation(datafile=expdata);
i.e. putting sig_u2 in the shocks block because this block is evaluated only once, but not over and over again during the estimation procedure
Nor can you do that
var x y;
varexo u1 u2;
parameters rhox rhoy sig_u2;
rhox = .8;
rhoy = .95;
sig_u2 = .02;
model;
x = 10*sig_u2*x(-1) + u1;
y = rhoy*y(-1) + u2;
end;
shocks;
var u1; stderr 0.01;
end;
estimated_params;
sig_u2, .01;
stderr u2, .01;
end;
varobs x;
estimation(datafile=expdata);
i.e. estimating directly the standard error of u2, because you would loose the constraint that standard error of u2 is equal to parameter sig-u2 that enters equation 1 of the model.
Best
Michel
[/code]
Excellent! Thanks so much. I am so glad to learn that Dynare can handle this… JP
Dear Michel,
I still I do not understand how to handle this issue. The reason: I have a simple model where two stderrs should be identified. When I introduce these as you suggested, estimation fails for one of them. By experimenting a bit I discovered that when I introduce the stderrs differently in the code, things work out fine. Do you know why this is the case? The answer to this is fundamental for our research. Please see the attached codes (model11.mod is the one that fails, model12.mod is the one that works, model12.mod is another way of writing the code that works, model14.mod is a related trick, but that fails (I could not upload it due to the 3 file restriction: it is using the same trick, but for sig_eps. You can verify that it won’t work)). We would really appreciate if you could explain how Dynare is evaluating the Likelihood in these cases, and where the estimations are coming from.
Thank you.
Meilleures salutations,
Jean-Paul
model13.mod (876 Bytes)
model12.mod (873 Bytes)
model11.mod (875 Bytes)
Dear Michel,
I was wondering if you had time to think about my problem (see preceding post). I am posting another example in which estimating the sigmas in one way or the other gives different standard errors for the estimates of the other parameters in the model (in this case, the ICFAs). Note that the fact that the sigmas enter in this example only in the var-cov matrix of the model permits me to estimate it one way or the other. I thought it would help you diagnose the issue.
Thanks a lot for your help
Jean-Paul
lforce_v1otherway.mod (2.4 KB)
lforce_v1.mod (2.4 KB)
The problems don’t come from where you expect.
AGAIN, I REPEAT:
you can not use a parameter in a shocks block and hope to estimate it!
So model12.mod and model13.mod seem to work but are WRONG!
model11.mod is correct, but the estimation doesn’t work because you use option lik_init=2. This option uses an arbitrarily large covariance matrix on the one step ahead error of forecast in the first period in the Kalman filter and was meant for non stationary models. If you remove lik_init=2 model11.mod preforms as expected.
lforce_v1otherway.mod has also lik_init=2. Please, try to remove it
Best
Michel
Dear Michel,
I am sorry but model11.mod without lik_init=2 does not work either – please have a look at the huge stderr of estimate for sig_e (67051.6293), indicating that there is a problem. I have attached my code, and I am using v.3 Snapshot version (the problem is still there with version 4). The parameter should be easily identified: write the equation for dc
dc = rho dc(-1) + (1-rho) (eps + e - e(-1))
where rho is a function of sig_eps and sig_e. So dc follows an arma(1,1). It is easy to see that if we were to estimate this equation, from the estimated arma coefficients we would get the two underlying parameters sig_e and sig_eps.
I did understand that I cannot put the parameter in the shocks sections, and hope to estimate them, as you previously explained. One reason I think model12.mod and model13.mod might work is that with simulated data the constraint on rho becomes slack and so the parameter can just be pinned down from the var-cov matrix of the shocks. But in general this won’t be the case. For some reason that I do not understand, in code model11.mod this does not happen.
Also, note that the equation for x in this model has a unit root, and therefore I thought that using lik_init=2 would be a way to alleviate the fact that the command unit_root_vars is not available (gives an error).
Thank you so much for your help.
Best regards,
Jean-Paul
model11.mod (864 Bytes)
Now, it is a different problem and it is introduced by the unit root in x and c that I didn’t see the first time around.
When you observe until dc, there is no information about the level of x and c. This shouldn’t matter for the estimation of the parameters, but currently, it creates a problem for computing the likelihood in Dynare. It requires a special initialization of the Kalman filter and I still have to work on how to do it correctly.
If you could rewrite the model so as to get rid of the unit root in unobservables, it would make things easier.
Best
Michel