Dev

dev@dynare.org

3402 discussions

Bug in likelihood functions of 4.3.1 and master
by Johannes Pfeifer 24 Oct '12

24 Oct '12

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

2 1

Status of testsuite in master branch
by sebastien＠dynare.org 23 Oct '12

23 Oct '12

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 23 Oct '12

23 Oct '12

*************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 192 tests PASSED out of 192 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 190 tests PASSED out of 190 tests run *************************************** A full log can be found on karaba in '/tmp/dynare-4.3-check-rjTn1yFphg.log'.

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 23 Oct '12

23 Oct '12

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 22 Oct '12

22 Oct '12

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 22 Oct '12

22 Oct '12

1 0

dsge_simulated_theoretical_variance_decomposition
by Johannes Pfeifer 21 Oct '12

21 Oct '12

Dear all, there seems to be a bug in dsge_simulated_theoretical_variance_decomposition (present at least since Dynare 4.2.5) that apparently sometimes leads to wrong output results. The critical part is 116-134: if linea == NumberOfDecompLines if posterior save([M_.dname '/metropolis/' M_.fname '_PosteriorVarianceDecomposition' int2str(DecompFileNumber) '.mat' ],'Decomposition_array'); else save([M_.dname '/prior/moments/' M_.fname '_PriorVarianceDecomposition' int2str(DecompFileNumber) '.mat' ],'Decomposition_array'); end DecompFileNumber = DecompFileNumber + 1; linea = 0; test = DecompFileNumber-NumberOfDecompFiles; if ~test% Prepare the last round... Decomposition_array = zeros(NumberOfLinesInTheLastDecompFile,nvar*nexo); NumberOfDecompLines = NumberOfLinesInTheLastDecompFile; DecompFileNumber = DecompFileNumber - 1; elseif test<0; Decomposition_array = zeros(MaXNumberOfDecompLines,nvar*nexo); else clear('Decomposition_array'); end end I dont understand the purpose of line 128 which is DecompFileNumber = DecompFileNumber - 1; We decrease the file number by one, but after line 122 increased it by one. As a result, if the model is large and the decomposition_array is split up in several files, the last file name in the save command gets the wrong number. For example, assume NumberOfDecompFiles=2. Now in the second step of the loop, we have DecompFileNumber=2 before entering the if-part. In the if-part DecompFileNumber will be set to 1 again and will be 1 when the save command is reached in the next iteration. As a consequence, the second Decomposition_array is written in file number 1 (and overwrites the previous ones) instead of number 2. I havent traced the consequences through the rest of compute_moments_varendo, but it seems as if the erased results are filled up with zeros, biasing the mean of the variance decomposition to 0 (and also affecting other statistics in a subtle way). At least that was how I noticed the mistake when working with Dynare 4.2.5. I think line 128 simply needs to be deleted. Best, Johannes -- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil.: +49-(0)170-6936820 Germany

2 1

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 21 Oct '12

21 Oct '12

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 21 Oct '12

21 Oct '12

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 20 Oct '12

20 Oct '12

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev