Unbounded density

Hi,

I use the Dynare 4.5.5 to estimate my DSGE model. There are warnings about unbounded density. However, I am confused that those unbounded densities are all following beta distribution. To my knowledge, beta distribution is bounded between 0 and 1, right?
How can I deal with this problem? Or I just need to change to another distribution, then which distribution is better?

Thanks

1 Like

You are talking about the support of the beta distribution. But the density is the “probability” of the value x occurring. If you look at the prior plots, you will see that there is an asymptote at 0 or 1 where the density/likelihood goes to infinity.

Thanks for letting me know this.
Could you please give me a hint on how to deal with this problem. Shall I change a prior or anything else?

Thanks

Yes, you need to change your prior. Given your prior mean, the prior variance is too big, putting mass into an asymptote.

Dear Prof. Pfeiper,

I read the following comments form your previous post:

“Yes, you need to change your prior. Given your prior mean, the prior variance is too big, putting mass into an asymptote.”

And I change the variance to a small number. But, there was an error immediately. Before I change the variance, the code could run about half and hour, and then showed up an error.The error was:

“Error using chol
Matrix must be positive definite.”

I am confused that why the erroe happended so fast after I changed the variance to a smaller number?

Thank you,
Alex

You need to have a look at the mode_check-plots. Maybe the optimizer failed to proceed. Did you try mode_compute=5?

I tried it, but it still does not work. However, Thank you for your advice.

Did you look at the mode_check-plots?

Thank you Prof. Pfeifer for your reply. I read the latest dynare menual about the mode_check. And i wrote the following command:
estimation(optim= (‘MaxIter’,3000),datafile=BayesianData3,xls_sheet=Sheet1,xls_range=B1:K216,mode_compute=6,first_obs=1, presample=4,lik_init=2,prefilter=0,mh_replic=10000,mh_nblocks=2,mh_jscale=0.50,mode_check_symmetric_plots=1,mh_drop=0.2);

But I did not see any plot. Could you tell me if the command that I wrote is correct or not? if not, what is the correct way to write the command?

Thank you,
Alex

You only need to add mode_check.

Thank you Prof. Peifer for your reply. I added it to my code, but there was nothing generated. I guess that the code needs to run to a certain point before the command mode_check starts to work. My code ran about half an hour and then stopped due to an error. I am not sure if my guess is correct. I look forward to your reply. Thank you Prof. Pfeifer.

Always provide the entire error message. But the plots should appear before an error can be triggered.

Thank you Prof. Pfeifer. I figured this out. Another question is what the diffrences are when we use different values for mode_compute. What should we consider When we pick the value of mode_compure? Or, the value does not matter as long as the estimation works.

You may find the following slides useful:


Thank you very much for answering my question. Another question is What should we consider when we pick the value of mh_replic. The biggre, the better?

Your only constraint is time. You want to be certain that you are properly sampling from the ergodic distribution. That’s why we check convergence diagnostics.

1 Like

Thank you Prof. Pfeifer for answering my question.

Thank you Prof. Pfeifer for providing your slides. It seems mode_compute=6 is a separate catogory. Can we say the value of 6 is the weakest (worst) one for estimation? and the value of 5 is the best one?
_

When I change the value of mh_replic, the IRFs will also change. Sometimes, a small value, like 10000, will make the IRFs look better (consistent with the intuition), however, a bigger mh_replic makes the IRFs look worse (not consistent with the intuition. Can I just choose the smaller value? Or, why does this happen?

  1. No, you cannot say that. It’s very context dependent and each optimizer has its strengths and weaknesses. mode_compute=6 tends to be slow and inefficient, but rather robust.
  2. That suggests your MCMC has not yet converged and you need more draws.