Default prior_trunc value / possible bug in write_latex_prior_table

Dear Dynare Team and Forum Users - happy (belated) 2025!

Sorry for spamming / the multiple posts, but I was having trouble getting the editor to understand my intentions :slight_smile:

Long story short, I was trying to understand how prior_trunc interacts with user-imposed bounds on parameters (when doing Bayesian estimation in dynare 6.2).

Two things caught my attention:

  1. I think the default value of prior_trunc is 2e-10 (and not 1e-32 as stated on p. 103 of the manual). I think zero would be most intuitive (particularly if the user has actually specified bounds), 1e-32 would probably be innocuous, but 2e-10 can visibly move the bounds in ways that someone unaware of the prior_trunc default might be surprised by (I know I was).

  2. What doesn’t help is that write_latex_prior_table (which would be the natural tool to check what the actual priors are) appears to be incorrectly reporting the bounds used (because it seems to ignore what the user specifies in the estimated_params block). I created two .mod files to illustrate both issues (attached below):

  1. In MWE_1.mod the estimated params block is:

estimated_params;
rho_x, 0.8341, 0.01, 0.955, BETA_PDF, 0.75, 0.05;
end;

and the estimation command doesn’t specify prior_trunc:

estimation(order=1, presample=15, datafile=‘MWE_data.csv’,lik_init=1, first_obs=1,mh_replic=000000, mh_nblocks=1, mh_jscale=0.33, mode_compute =1, optim=(‘MaxIter’, 100000),irf=40);

The MWE_1_priors_table.tex file created by write_latex_prior_table; then states that options.prior_trunc=1e-10, which would suggest that it is the default value.

However, MWE_1_priors_table.tex also reports that the lower and upper bounds are 0.3872 and 0.9611 respectively. It is easy to check that to hit the required mean of 0.75 and std of 0.05 we need a beta distribution with parameters 55.5 and 18.5 and it also holds that:

betacdf(0.3872,55.5,18.5) = 9.979370411264600e-11
betacdf(0.9611,55.5,18.5) = 0.999999999899635

In other words, dynare seems to be cutting off 1e-10 on both sides of the beta distribution, and so, in effect, cuts off 2e-10 worth of “probability mass”. I.e., significantly more than 1e-32 would imply (in the example, this moves the lower bound from 0.01 to 0.3872; which is kind of a large move if someone wasn’t expecting it…).

  1. The priors table also suggests a second issue, as the upper bound appears higher than the user-specified upper bound of 0.955. I checked and I think this is purely a reporting error caused by write_latex_prior_table;. I.e., I think dynare correctly applies the intersection of the two sets of bounds, but write_latex_prior_table only reports those implied by prior_trunc (either its default value or that specified by the user).

To illustrate that, in MWE_2, I used the prior_trunc=0 option when estimating. The corresponding MWE_2_priors_table.tex then states that the lower bound is 0 and that the upper bound is 1, whereas they actually are 0.01 and 0.955 (specified in the estimated_params block).

Hope this helps, replication files attached below. As always, happy to stand corrected if I’m missing anything / things were meant to work this way.

Thanks again for all the good work!
paw

MWE_1.mod (1.0 KB)
MWE_2.mod (1.0 KB)
MWE_data.csv (2.0 KB)

  1. Yes, the default is 1-e10 on each side of the distribution. I will correct the manual. That truncation leaves 0.9999999998 of the probability mass still intact. This type of truncation will therefore only move the prior bounds significantly in regions that are extremely unlikely. In most cases, that should therefore not make much of a difference. But it can do so if the very unlikely prior region gets assigned a large weight in the posterior so that you hit the bounds.
  2. To understand the behavior of write_latex_prior_table, you need to understand the design of the prior bounds. As documented in the manual, the bounds in the estimated_params and estimated_params_bounds do the following:

Specifies a lower bound for the parameter value in maximum likelihood estimation. In a Bayesian estimation context, sets a lower bound only effective while maximizing the posterior kernel. This lower bound does not modify the shape of the prior density, and is only aimed at helping the optimizer in identifying the posterior mode (no consequences for the MCMC)

Thus, the actual prior distributions used in Bayesian estimation are not affected and the computed table reflects this. That is different for options.prior_trunc which will be operative in all cases.

Thanks, Johannes - this is super helpful!

And I didn’t realize that prior_trunc is, in some sense, more general than the constraints imposed via estimated_params, so that’s very useful to know - thanks.

Not a high level priority, and possibly something that is already available (?), but being able to see the constraints in effect while maximizing the posterior kernel would be quite helpful (I guess we can combine the latex_prior_table with the bounds from the estimated_params block, but when estimating tens of parameters that can be a bit cumbersome). Reason for flagging: we were bumping into the bounds without realizing it (courtesy of prior_trunc>0), which only your post alerted us to. And I’m hoping we would have spotted this ourselves if the output of posterior kernel maximization also reported the actual bounds. Naturally, and per your parallel reply, the big picture question is why we end up in these “highly unlikely” regions of the parameter space to begin with, which is something we’re chewing on now…

Anyway, thank you so much for your continued and tireless help and sharing the insights above!
paw

I opened a ticket about removing the prior truncation: Potentially remove options_.prior_trunc (#1953) ¡ Issues ¡ Dynare / dynare ¡ GitLab

1 Like