bug in prior_bounds.m

[lombard]

Hi,

I think there is a bug in prior_bounds.m.
In the comments on top of the file it is written that it returns bounds in the order upper & lower.
Then this order is followed if prior_trunc==1 but the opposite order is followed if prior_trunc==0;

The dynare_estimation_init.m file that calls prior_bounds expects to find bounds in the order lower & upper.

In the amended file here attached I've switched the order set under prior_trunc==1. This seems to work when initial values
are provided in the same block where priors are given.

Best
Gianni

PS: I'm using v4.3.0 unstable

[jpfeifer]

Could you provide an example? I checked the file in the snapshot and think it is correct (the comments are a bit confusing and will be corrected). Moreover, if I use your file, Dynare crashes because the lower bounds are larger than the upper bounds. For example you changed the ordering to

Code: Select all

                bounds(i,2) = gaminv(prior_trunc,p6(i),p7(i))+p3(i);
                bounds(i,1) = gaminv(1-prior_trunc,p6(i),p7(i))+p3(i);


Hence, the lower bound in bounds(i,1) is now set to the point where the cdf reaches 1-prior_trunc. This clearly is the upper bound.

[lombard]

Note that I defined the priors in this way

Code: Select all

parameter name, initial value, ,, shape, etc.


that is with empty upper and lower bounds following the initial value. Then, the original prior_bounds.m was generating the error due to inverted order of bounds. Note that the ub and lb generated by the missing bounds in the declaration are vectors of NaN. These are overwritten by the output of prior_bounds.m.

This did not happen when I declared priors and initial values in two separate blocks (I thought that in that case prior_bounds would not be used but I didn't check).

Now the server here is down so I cannot post the code. But is should be possible to replicate it with the above description using one of the example models (e.g. fs200)

Best

Gianni

[jpfeifer]

I tested exactly this specification (and some others) and cannot replicate the problem. Hence, the mod-file would be extremely helpful.

[lombard]

Would the prior block suffice (I cannot post the whole model at this stage)

Best

Gianni

[jpfeifer]

I might have found the source of the problem. You wrote:

In the amended file here attached I've switched the order set under prior_trunc==1.

But prior_trunc can never be 1. I think the syntax of prior_trunc was changed some time ago. If I remember correctly, it used to be a binary variable. But now the manual says for prior_trunc:

Probability of extreme values of the prior density that is ignored when computing
bounds for the parameters. Default: 1e-32

Thus, when you set it to 1, 100% of the probability mass, i.e. everything, is ignored.