I have to correct my previous message. filter_step_ahead and filtered_vars are two distinct things. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&p=12780&sid=b5eb85128d1c094f0a84366c55c411e9#p12780 for a discussion of the problem.

Instead of saving in different fields, we actually rule out filter_step_ahead for Bayesian estimation and do not elaborate on this in the manual. Is there a particular reason for not allowing this? The code itself seems to work after Bayesian estimation.

Johannes Pfeifer

Haußerstr. 29

72076 Tübingen

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

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

Germany

Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Johannes Pfeifer
Gesendet: Mittwoch, 25. September 2013 11:16
An: Dev@dynare.org
Betreff: [DynareDev] filter_step_ahead

Dear all,

could it be that there is a mistake in the manual? It currently says:

filter_step_ahead = [INTEGER1:INTEGER2]

Triggers the computation k-step ahead filtered values. Stores results in oo_.FilteredVariablesKStepAhead and oo_.FilteredVariablesKStepAheadVariances.

But this seems to be only true for “%% ML estimation, or posterior mode without metropolis-hastings or metropolis without bayesian smooth variable“ as the comment in dynare_estimation_1 before the call to DsgeSmoother says. Instead, for Bayesian estimation, the respective field seems to be oo_.filtered_variables.