Dear Johannes,

thanks for spotting that. I have added penalized values for fval in dsge_likelihood.m Similar tests are not performed in DsgeVarLikelihood.m and maybe we should add them as maybe in non_linear_dsge_likelihood.

We should also check how the arguments returned by the likelihood functions are used. The situation is different in Newton based optimizers or in Metropolis simulations. With Newton based optimizers, we want to avoid cliffs due to penalty and rely on fval to lead the algorithm towards the mode. In Metropolis simulatioins, we want to discard cases when we encountered any problem in the computation of the likelihood and we should rely on exit_flag. But I'm not sure that all the code is really doing that. I will open a ticket.

Best

Michel

On 10/23/2012 10:39 PM, Johannes Pfeifer wrote:

Dear all,

1.there is a bug in Dynare 4.3.1 and master that leads to crashes of estimation/mode computation. It affects dsge_likelihood and potentially other functions like DsgeVarLikelihood. Currently, we initialize

fval=[];

Later in the file, we have two checks for the likelihood

ifisnan(LIK)

info = 45;

exit_flag = 0;

return

end

ifimag(LIK)~=0

info = 46;

exit_flag = 0;

return

end

The problem is that we did not set the return argument fval. Hence, subsequent checks as in gmhmaxlik of the form

ifall(proposal > mh_bounds(:,1)) && all(proposal < mh_bounds(:,2))

    logpo2 = - feval(ObjFun,proposal,varargin{:});

else

    logpo2 = -inf;

end

% I move if the proposal is enough likely...

iflogpo2 > -inf && log(rand) < logpo2 - ilogpo2

fail, because logpo2 is empty. In random_walk_metropolis_hastings_core we have the same check.

I am not sure how to deal with this issue. Generally, it would be easiest to initialize fval to NaN instead of []. What is the current convention regarding the output of the likelihoods? Sometimes we return a penalty, sometimes NaN and sometimes nothing, while we do not always check the exit flag.

Moreover, note that we later check:

ifimag(fval)~=0

info = 48;

exit_flag = 0;

return

end

This means that dsge_likelihood actually returns an imaginary value which then enters the above check in gmhmaxlik. I think it should never be the case that we actually return a complex value. This issue would not be solved by initializing fval to NaN and might lead to problems.

Thus, my preferred solution would be to explicitly set fval=NaN directly in front of the return statements for cases 45,46, and 47. Similar issues seem to appear in DsgeVarLikelihood, but I am not familiar with this part of the code.

2.Only non_linear_dsge_likelihood does not suffer from the same problems, but this is to some degree because we do not have the same error codes and do not do the same checks. There is for example currently not a check for imaginary or NaN priors. Should we open a ticket for this?

Regards,

Johannes

--

Johannes Pfeifer

Haußerstr. 29

72076 Tübingen

Tel.: +49-(0)7071-6396184

Mobil.: +49-(0)170-6936820

Germany

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev