Thanks Johannes. You are right. I fixed the bug. Having to write a bunch of identical files and then a shorter one appears in many places and is often source of trouble. We should agreed on an unified way of doing it and maybe factorize the code.

Best

Michel

On 10/20/2012 11:40 PM, Johannes Pfeifer wrote:

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:

iflinea == NumberOfDecompLines

ifposterior

            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;

elseiftest<0;

            Decomposition_array = 

zeros(MaXNumberOfDecompLines,nvar*nexo);

else

            clear('Decomposition_array');

end

end

I don't 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 haven't 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

---

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