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

 

if isnan(LIK)

    info = 45;

    exit_flag = 0;

    return

end

 

if imag(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

 

    if all(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...

    if logpo2 > -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:

if imag(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