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 http://www.dynare.org/phpBB3/viewtopic.php?f=1&p=12780&sid=b5eb85128d1c094f 0a84366c55c411e9#p12780 &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.
Best,
Johannes
--
Johannes Pfeifer
Haußerstr. 29
72076 Tübingen
Tel.: +49-(0)7071-6396184
Mobil.: +49-(0)170-6936820
Germany