9/4/2015

Advanced Dynare programming

Tom Holden

Friday, 04 September 2015 1

Introduction
This section

• In this section, I will introduce you to some of Dynare’s less well known
features, including:
• The pre-processor.
• Model local variables.

• We will also look at Dynare’s internals, both to better understand what

Dynare is doing, and to enable us to introduce new Dynare features.

• We will also look at hybrid simulation methods, and assess the accuracy of
Dynare’s different approximations.

Friday, 04 September 2015 2

1
 9/4/2015

The pre-processor language

Basics

• Before the .mod file is passed to the main Dynare processing engine, it first
goes through a pre-processor.
• This parses the original .mod file and generates a new .mod file from it.

• Commands may be passed to the pre-processor using lines beginning with

the symbols “@#”.
• @#define VariableName = VariableValue sets the value of a
pre-processor variable. (This variable is only known to the pre-
processor, not to Dynare or MATLAB.)
• @#for Index in Array … @#endfor starts a pre-processor for
loop. The pre-processor will iterate over the elements of Array.
• @#if … @#else … @#endif gives a pre-processor conditional.
• The text representation of a pre-processor variable may be inserted in to the
generated .mod file using @{VariableName}.

Friday, 04 September 2015 3

The pre-processor language

A first example

• The file Primes.mod illustrates the basic features of the pre-processor.

• To see what the pre-processor is doing, we can ask it to save the

intermediate .mod file using “dynare Primes.mod savemacro
nolinemacro”.
• By default, Dynare does not save the pre-processor’s output.

• Note that the “in” operator is testing if an array contains an element.

• Also note that + and - on arrays performs concatenation and set-difference,

respectively.

Friday, 04 September 2015 4

2
 9/4/2015

The pre-processor language

Other pre-processor variable operations

• Pre-processor arrays may be dereferenced with MATLAB style syntax, but with
square brackets.
• E.g. MyArray[3] or MyArray[4:8].
• The length operator returns the length of an array.
• E.g. length(MyArray).

• Pre-processor strings are defined by text in double quotes, e.g.: “a string”.

• The previously mentioned two operations can also be performed on pre-
processor strings.
• Furthermore, on pre-processor strings, + performs concatenation and ==
and != test for equality and inequality respectively.

• The pre-processor also supports integer variables (not doubles!), which support
standard arithmetic and logical operations.
• Note that negation is ! not ~.

Friday, 04 September 2015 5

The pre-processor language

Other pre-processor commands

• The pre-processor also supports the following commands:

• @#include “ModFileName.mod” which inserts the contents of the
.mod file ModFileName.mod.
• @#echo which displays the following text to the user of the .mod file.
• @#error which stops further pre-processing, and quits Dynare.

• Examples of these commands will be seen shortly.

Friday, 04 September 2015 6

3
 9/4/2015

The pre-processor language

The difference between pre-processor variables and model local variables.

• Model local variables (MLVs) are defined by lines starting with a “#” and
ending with a semi-colon.
• E.g. #PI = exp(pi);.
• Model local variables are interpreted by the main Dynare processor, and they
can only occur within the model block.
• Dynare effectively copies and pastes the contents of the model local variable
into all of the equations in which it is used, surrounding the entire variable
with brackets.

• Similar results may be accomplished with both MLVs and pre-processor

variables.
• The chief difference between the two is that while the pre-processor variable
is effectively copied and pasted in as is, the MLV is effectively copied and
pasted in surrounded by brackets.
• This is illustrated in MLVTest.mod.

Friday, 04 September 2015 7

The pre-processor language

More on model local variables.

• A further difference between MLVs and pre-processor variables is that

whereas the pre-processor cannot write another definition for a pre-processor
variable, the pre-processor can be used to create definitions of new MLVs.
• I will illustrate the use of this feature in code for creating automatically
defined transformed variables.

• One limitation of MLVs is that some of Dynare’s solution algorithms do not

currently support them (e.g. those using the block decomposition, or those
using byte-code).
• To work around this, I have written an alternative pre-processor which
generates a new .mod file by replacing each use of a model local
variable by its definition.
• The source and binary releases are available from:
https://github.com/tholden/DynareRemoveLocalVariables

Friday, 04 September 2015 8

4
 9/4/2015

The Dynare variable transformation engine

Rationale

• Approximation accuracy can usually be increased by defining each variable

under a transformation such that the transformed variable can take values on
the whole real line.
• E.g., since output is always positive, we should work with the logarithm of
output, not its level.
• If we do not this, and the variance of shocks is large, then we can easily end
up with e.g. a negative mean capital stock.

• Some macroeconomic variables such as utilisation are bounded both above

zero and below one.
• For these variables, we should work with the “logit” transform of the variable,
௣
where logit ‫ ݌‬ൌ log , as this maps the interval 0,1 to െ∞,∞ .
ଵି௣

• More generally, we might first linearly transform the source variable, then take
logarithms or logits, then linearly transform the result.

Friday, 04 September 2015 9

The Dynare variable transformation engine

A surprising example of a variable bounded both above and below

• Consider a basic New Keynesian model, such as that of Fernández-

Villaverde et al. (2012).
• In this model:
భ
ଵ
• The price-level is given by: ܲ ௧ ൌ ܲ ଵିఌ ܲ ‫݌‬భష௣.
௣
• A fraction 1 െ ௣of all firms update their price to ܲ ௧∗ in period ‫ݐ‬.
• Hence: ܲ ௧ଵିఌ ൌ ௣
ܲ ଵିఌ ௣ 1െ௣ܲ ௧∗ଵିఌ.
• If we define gross inflation by Π௧ ≔ ௣௣ and the relative reset price by Π∗ ≔
∗ ௣௣షభ
௣௣
, then the evolution of inflation is governed by: 1 ൌ ௣Πఌିଵ ௣ 1െ௣Π∗ଵିఌ.
௣௣
• Now, ௣௣1 else the firm’s optimal price decision is unbounded, so Π௧ is
maximised when1 െ ௣Π∗ଵିఌ is as small as possible (i.e. zero).
భ
• Thus Π௧ ௣௣
భష௣!

• ௣ൌ 0.75, ௣ൌ 6 implies Π௧ ௣1.06.

Friday, 04 September 2015 10

5
 9/4/2015

The Dynare variable transformation engine

Design for a Dynare transformation engine

• The Dynare transformation engine is a set of .mod files which, when

@#included into another .mod file, automatically transform variables so that
they take values on the entire real line.
• Rather than declaring variables with var, we will define a pre-processor array
of the form
EndoVariables=["VariableName1","Minimum1","Maximum1",
"VariableName2","Minimum2","Maximum2", ...], where we allow
“Minimum*” to take the special value “-Inf” and “Maximum*” to take the
special value “Inf”.
• The transformation engine loops through the elements of this array, declaring
the appropriately transformed variables.
• It then generates model local variables defining the untransformed variables
in terms of the transformed ones.
• Finally, it defines the steady-state for the transformed variables in terms of
the provided steady-state for the untransformed ones.

Friday, 04 September 2015 11

The Dynare variable transformation engine

Dynare transformation engine implementation

• The Dynare transformation engine is implemented in the files:

• Initialize.mod
• ClassifyDeclare.mod
• InternalClassifyDeclare.mod
• InsertNewModelEquations.mod
• InsertNewSteadyStateEquations.mod

• We will go through this code together.

Friday, 04 September 2015 12

6
 9/4/2015

The Dynare variable transformation engine

Testing the Dynare transformation engine

• We test the transformation engine on a slightly modified version of the NK model

of Fernández-Villaverde et al. (2012).
• We modify the utility function so that utility goes to െ∞ as ‫ܮ‬௧ → 1.
• We modify the laws of motion of ௣௧ (the discount factor), so that it is AR(1)
in logits, rather than AR(1) in logs.
• Likewise, we modify the law of motion for the ܲ ௣,௧ (the government
spending share), so that it is AR(1) in logits as well.

• The original .mod file is NK.mod, and the version using our transformation engine
is in NKTrans.mod.
• In the model block, we just have to perform a search and replace of (+1)
for _LEAD and (-1) for _LAG.
• Note that we had to slightly modify the steady_state_model block
because Dynare does not allow us to introduce new variables in the
steady_state_model block with the same name as MLVs.

• Compare the results of the transformed and untransformed files when ௣

௣is
increased from 0.26 to 0.27.

Friday, 04 September 2015 13

Further model transformation

(Manual) equation transformation and MLV introduction

• Approximation accuracy can generally be increased by applying similar

transformations to both sides of each of the model’s purely backwards looking
equations.
• If both sides of a backwards looking equation are positive, we should take
logarithms of both sides.
• We cannot do this to forward looking equations due to Jensen’s inequality.

• Both accuracy and simulation/estimation speed can generally be increased by

replacing as many equations as possible by model local variables.
• It is normally possible to transform each equation with no leads or lags
into an equation defining a model local variable.
• Some equations containing lags can also be transformed in this way (but
you can never have a state variable as an MLV).
• Equations containing leads cannot be converted into MLV definitions,
again due to Jensen’s inequality.

• Have a go at applying these two sets of transformations to NKTrans.mod.

• Does it speed up simulation?

Friday, 04 September 2015 14

7
 9/4/2015

Further model transformation

Automatic definition of shock processes

• Defining the laws of motion for shock processes is tedious, particularly when
the shocks processes are transformed, as they are here.

• As a final example of the pre-processor, examine the files CreateShocks.mod

and InsertNewShockBlockLines.mod from the transformation engine, which
may be used for automatically declaring shock processes.

• The use of these files is demonstrated in NKTrans3.mod.

• The complete transformation engine including this code will always be

available from: https://github.com/tholden/DynareTransformationEngine

Friday, 04 September 2015 15

Dynare’s internals
Why is understanding Dynare’s internals useful?

• If you want to customise Dynare’s behaviour, then delving into Dynare’s

internals is often inescapable.
• For example, in the past I have changed Dynare code to perform tasks
including:
• Implementing simulated moment restrictions in maximum likelihood
estimation.
• Imposing a smooth penalty during estimation on nearly non-stationary
models.
• Solving a particular class of models not handled by Dynare (those
with occasionally binding constraints).
• Increasing the robustness of various Dynare solvers.
• Working around various internal Dynare bugs (of which there are still
many).

• It is also helpful to know Dynare’s internals so that you can better understand
why Dynare acts the way it does.

Friday, 04 September 2015 16

8
 9/4/2015

Dynare’s internals: Key Dynare Files

Steady-state solution files

• evaluate_steady_state.m
• Finds the model’s steady-state, either via calling a user provided
_steadystate.m file, an automatically generated steadystate2.m file, or
via a numerical search using dynare_solve.m.

• dynare_solve.m
• Finds the model’s steady-state via a numerical search.
• It is easy to customise this file to use an alternative solver, such as
CMA-ES.

• resid.m
• Returns the residuals of the model’s static equations at the steady-
state.
• Internally calls the automatically generated _static.m file.
• Useful for debugging a steady-state.

Friday, 04 September 2015 17

Dynare’s internals: Key Dynare Files

Stochastic model solution and simulation files

• resol.m
• First finds the model’s steady-state (using evaluate_steady_state.m), then
solves the model, via a call to stochastic_sovers.m.
• Returns the structure dr with the model’s transition matrices, and a flag
info which reports problems solving the model.
• We will modify this file in the non-linear estimation section in order to
implement two alternative solution procedures.

• stochastic_sovers.m
• Does the work of solving the stochastic model.
• Placing breakpoints here can help debug failures of the BK conditions.

• simult.m
• Responsible for simulation of stochastic models.
• Useful to modify this file if you want to use specific shocks for a
simulation.
• The work is done in simult_.m, which we will look at in more detail shortly.

Friday, 04 September 2015 18

9
 9/4/2015

Dynare’s internals: Key Dynare Files

Deterministic model simulation files

• simul.m
• Responsible for simulation of deterministic models.
• If you develop a new algorithm for solving deterministic models, you
might modify this file.
• Most of the work is done in sim1.m, when using the default algorithm.

• sim1.m
• Does the work of simulating the deterministic model.
• Placing breakpoints here can help understand failures of
convergence.
• Additionally, it sometimes helps to change the line dy = -A\res; to
use a more robust solver.
• The provided dynare repository contains two, lin_solve and
lin_solve_robust which can be used with dy = -
lin_solve(A,res); and dy = -lin_solve_robust(A,res);.

Friday, 04 September 2015 19

Dynare’s internals: Key Dynare Files

Estimation files

• dsge_likelihood.m
• Returns the negative log-likelihood to a first order approximation to the
model.
• dynare_resolve.m is used to solve the model, which expands the
transition matrices from resol.m into square matrices.
• There is a lot of scope for customising this file, including:
• Modifying the initial covariance matrix of the state, through adding
extra options to the switch DynareOptions.lik_init block.
• Changing what happens when the BK conditions are not satisfied, by
e.g. returning the likelihood under some indeterminate solution.
• Better handle errors using try { } catch { } blocks.
• Adding custom priors by subtracting something from xparam1.
• Adding a custom prior penalising nearly non-stationary models via
subtracting some increasing function of log(1-abs(eigs(T,1))).

• non_linear_dsge_likelihood.m
• Returns the approximate negative log-likelihood of a non-linear model via
the particle filter.

Friday, 04 September 2015 20

10
 9/4/2015

Dynare’s internals: Dynare’s input and output structures

The M_ structure

• M_ contains details about the model, including:

• The names and number of endogenous variables, exogenous variables
and parameters, in M_.endo_names, M_.endo_nbr, M_.exo_names,
M_.exo_nbr, M_.param_names and M_.param_nbr.
• The parameter values in M_.params.
• Parameters in declaration order.
• The covariance matrix of exogenous shocks in M_.Sigma_e.
• Shocks in declaration order.
• The number of static variables (M_.nstatic), only future dated variables
(M_.nfwrd), only past dated variables (M_.npred), both future and
backwards dated variables (M_.nboth), somewhere future dated
variables (M_.nsfwrd), somewhere past dated variables (M_.nspred),
somewhere future or past dated variables (M_.ndynamic).
• A 3 by M_.endo_nbr matrix in which the first row corresponds to the
variables which are lagged somewhere, and the last row corresponds to
the variables which are leaded somewhere.

Friday, 04 September 2015 21

Dynare’s internals: Dynare’s input and output structures

The oo_ structure

• oo_ contains details about the results of solving the model, including:
• Its steady state in oo_.steady_state, its mean in oo_.mean, and its
covariance in oo_.var.
• All in declaration order.
• The auto-covariance of the model’s variables in oo_.auto_corr.
• Row i of oo_.auto_corr{n} gives the correlation between the i th
endogenous variable and the nth lag of all endogenous variables.
• The steady state of the exogenous variables in
oo_.exo_steady_state for stochastic exogenous variables, and in
oo_.exo_det_steady_state for deterministic exogenous variables.
• The generated simulation paths in oo_.endo_simul (for endogenous
variables), oo_.exo_simul (for stochastic exogenous variables) and
oo_.exo_det_simul (for deterministic exogenous variables).
• Each matrix has columns indexed by time.
• The generated impulse responses in oo_.irfs.

Friday, 04 September 2015 22

11
 9/4/2015

Dynare’s internals: Dynare’s input and output structures

The oo_.dr structure and the internals of simult_.m (1/2)

• The most important part of oo_ is oo_.dr which stores the decision rules of the
model.
• The matrices dr.ghx and dr.ghu play a similar role to ௣and ௣in the
VAR(1) ‫ݔ‬௧ ൌ ௣ ‫ݔ‬௧ିଵ ௣௣
௣௧.
• However, dr.ghx is not in fact square, and its rows and columns are not
in declaration order!

• Suppose yOld is the value of all endogenous variables at the end of last period,
in declaration order.
• Then yOldDr = yOld( dr.order_var ); is the values of these old
variables in “dr order”.
• dr.order_var maps dr order to declaration order.

• dr.ghx has as many columns as there are state variables in the model.
• In dr order, all of the state variables are next to each other, immediately
after all of the static variables.
• Using this information, can you produce a vector that indexes all of the
state variables in dr order?

Friday, 04 September 2015 23

Dynare’s internals: Dynare’s input and output structures

The oo_.dr structure and the internals of simult_.m (2/2)

• Let select_state be the vector you found in the last slide.

• Or see page 70 of the notes.
• Then, yOldState = yOldDr( select_state ); gives the old state
variables in dr order.
• Given this, simulating the first order approximation to a model forward one
period is as simple as: yNewDr = dr.ghx * yOldState + dr.ghu *
chol( M_.Sigma_e, 'lower' ) * epsilon;.
• Then to map back to declaration order we just use yNew = yNewDr(
dr.inv_order_var ).

• Have a go at writing code to generate simulation paths for the first order
solution to a model.

Friday, 04 September 2015 24

12
 9/4/2015

Dynare’s internals: Higher order pruned simulation

Motivation and background to pruning

• We have already seen that third order approximations can lead to explosive
paths.
• To see the intuition for this, suppose that ‫ݔ‬௧ evolves according to an equation
of the form ‫ݔ‬௧ ൌ ⋯ ௣‫ܣ‬ଶ ‫ݔ‬௧ିଵ ⊗ ‫ݔ‬௧ିଵ௣⋯, then from iterating this equation
we have that:
• ‫ݔ‬௧ ൌ⋯௣‫ܣ‬ଶ ‫ܣ‬ଶ ⊗‫ܣ‬ଶ ‫ݔ‬௧ିଶ ⊗‫ݔ‬௧ିଶ ⊗‫ݔ‬௧ିଶ ⊗‫ݔ‬௧ିଶ ௣⋯
• ‫ݔ‬௧ ൌ ⋯௣‫ܣ‬ଶ ‫ܣ‬ଶ ⊗ ‫ܣ‬ଶ ‫ܣ‬ଶ ⊗ ‫ܣ‬ଶ ⊗ ‫ܣ‬ଶ ⊗ ‫ܣ‬ଶ ሺ‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷ ⊗
‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷ ⊗ ‫ݔ‬௧ିଷሻ ௣⋯

• “Pruning” is one solution to this problem, first introduced by Kim et al. (2008).
• There are many different pruned solutions, but all of them are
designed to remove these high order terms in past states.

Friday, 04 September 2015 25

Dynare’s internals: Higher order pruned simulation

Background to the Lan and Meyer-Gohde (2013b) pruned solution

• Given the multiple ways of performing pruning, any particular pruned solution can
appear a little ad hoc.
• Lan and Meyer-Gohde (2013b) give a proper foundation for a particular type of
pruned solution.
• Suppose we introduce an extra parameter to our model ௣which pre-
multiplies all of the model’s shocks.
• ௣ൌ 1 corresponds to the original solution.
• The traditional unpruned perturbation solution is formed by taking a Taylor
approximation to the (unknown) function ‫ݔ‬௧ ൌ ܲ ௣ , ‫ݔ‬௧ିଵ, ௣௧around ௣ൌ 0,
‫ݔ‬௧ିଵ ൌ ‫ݔ‬, ௣௧ ൌ 0 (e.g. the non-stochastic steady state).
• Lan and Meyer-Gohde (2013b) propose to instead take a Taylor
approximation to the (unknown) function ‫ݔ‬௧ ൌ ‫ݔ‬௣ , ௣௧, ௣௧ିଵ, … , again
around ௣ൌ 0, ௣௧ ൌ ௣௧ିଵ ൌ ⋯ ൌ 0.
• It turns out that the Taylor approximation to this non-linear moving
average representation has a recursive representation of the same broad
form of the pruned solutions previously considered in the literature.
• Lan and Meyer-Gohde (2013a) show that their pruned solution is more
accurate than all of the others considered in the literature.

Friday, 04 September 2015 26

13
 9/4/2015

Dynare’s internals: Higher order pruned simulation

Using the Lan and Meyer-Gohde (2013b) pruned solution

• Lan and Meyer-Gohde released a Dynare toolkit for their solution method.
• A version of this code is available from
https://github.com/tholden/nlma or from the nlma folder.
• The easiest way to use this toolkit is with the help of another toolkit by me for
handling occasionally binding constraints (OBC) in DSGE models.
• This toolkit is available from https://github.com/tholden/OBCToolkit of
from the OBCToolkit folder.
• The toolkit takes care of changing calls to stoch_simul to calls to the
NLMA toolkit, even in models without OBC.
• To use the OBCToolkit on a model without OBC, it is best to invoke it with:
dynareOBC ModFileName.mod irfsaroundzero.
• It can also handle taking a first order approximation around the risky steady-
state or the mean (using code from Meyer-Gohde (2014)) by setting order=2
or order=3 in the .mod file and then calling: dynareOBC ModFileName.mod
irfsaroundzero firstorderaroundrss or …
firstorderaroundmean.

Friday, 04 September 2015 27

Dynare’s internals: Uses of the _dynamic.m files

The _dynamic.m files

• One of the main outputs of Dynare’s pre-processor is the generated

ModFileName_dynamic.m files.
• These files are used by Dynare for perfect foresight solution, and for
constructing the model’s transition matrices.
• They output the dynamic residuals of the model.

• Their inputs are:

• The lags, current values and leads of the endogenous variables, all
stacked into a single vector in the order determined by the rows of
M_.lead_lag_incidence.
• The values of the exogenous variables in a multi-column matrix, with rows
in declaration order, and columns corresponding to time-periods.
• The values of the parameters in declaration order.
• The variable’s values at the model’s steady-state, in declaration order.
• An iterator which determines the column index into the matrix of
exogenous variables to use for today’s shock.

Friday, 04 September 2015 28

14
 9/4/2015

Dynare’s internals: Uses of the _dynamic.m files

Using the _dynamic.m files for the simulation of MLVs

• If we examine one of these files, we see that it contains code to evaluate the
exact value of each MLV in terms of the function’s inputs.
• Suppose we wish to simulate the MLVs Y, C, PI and R from NKTrans3. Modify the
generated _dynamic.m file so that it returns these four MLVs in a vector.
• Once we have a function that returns the MLVs we need, it is then quite straight-
forward to write code to calculate the path of MLVs along a simulation.
• Code to do this is shown in SimulateMLVs.m.
• As an alternative to manual editing of the _dynamic.m files, the OBC toolkit can
automatically generate simulations for MLVs.
• Just add their names after the call to stoch_simul as you would with an
endogenous variable, and then call dynareOBC with
MLVSimulationMode=1.
• It can also generate average IRFs for model local variables via the
slowirfs option.
• Finally, it can generate simulations for the expected value of a forward
looking model local variable if called with MLVSimulationMode=2 or
MLVSimulationMode=3.

Friday, 04 September 2015 29

Dynare’s internals: Testing the accuracy of Dynare

Dynamic (Euler) equation errors

• We will use the Jin and Judd (2002) method for assessing the accuracy of an
approximation.
• For each equation of the form lhs௧ ൌ ॱ௧rhs௧ାଵ, we form the
lhs௣ିॱ௣rhs௣శభ
normalized, dimension free, error error௧ ൌ
lhs௣
• More generally for each equation of the form lhs௧ ൌ rhs௧ (where either
or both sides may contain expectations), we form the normalized,
lhs௣ିrhs௣
dimension free, error error௧ ൌ
lhs௣
• These should be zero over the entire state space.
• In practice, we just check how close to zero they are over a simulation
path.
• To evaluate these errors we use the capabilities of the author’s OBC toolkit.
• Have a go at modifying NK.mod and NKTrans4.mod to calculate the
error for each of the 16 original equations.

Friday, 04 September 2015 30

15
 9/4/2015

Dynare’s internals: Testing the accuracy of Dynare

Accuracy comparison of the transformed and untransformed models

Table 3.1: Comparison of the accuracy of NKAccuracy.mod and NKTrans4Accuracy.mod

Original Original model errors Transformed model errors Improvement in errors
equation M ean Root mean M aximum M ean Root mean M aximum M ean Root mean M aximum
number absolute squared absolute absolute squared absolute absolute squared absolute
1 8.08E-05 1.05E-04 5.27E-04 4.93E-04 1.82E-03 4.41E-02 -4.12E-04 -1.72E-03 -4.36E-02
2 1.32E-05 3.12E-05 4.75E-04 0.00E+00 0.00E+00 0.00E+00 1.32E-05 3.12E-05 4.75E-04
3 4.21E-06 7.97E-06 7.76E-05 0.00E+00 0.00E+00 0.00E+00 4.21E-06 7.97E-06 7.76E-05
4 9.93E-17 1.35E-16 4.39E-16 4.15E-17 7.34E-17 2.21E-16 5.77E-17 6.14E-17 2.18E-16
5 9.73E-04 1.37E-03 1.22E-02 5.94E-04 7.87E-04 5.64E-03 3.79E-04 5.85E-04 6.52E-03
6 7.51E-04 1.08E-03 1.05E-02 4.54E-04 6.17E-04 4.96E-03 2.97E-04 4.66E-04 5.55E-03
7 9.32E-06 1.14E-04 2.98E-03 5.44E-04 1.88E-03 4.38E-02 -5.34E-04 -1.77E-03 -4.08E-02
8 2.33E-06 4.31E-06 3.99E-05 0.00E+00 0.00E+00 0.00E+00 2.33E-06 4.31E-06 3.99E-05
9 4.61E-04 7.88E-04 8.07E-03 2.31E-17 5.18E-17 2.22E-16 4.61E-04 7.88E-04 8.07E-03
10 6.71E-04 1.14E-03 1.15E-02 1.29E-04 2.81E-04 3.35E-03 5.42E-04 8.58E-04 8.13E-03
11 7.61E-17 1.16E-16 4.74E-16 2.01E-17 5.57E-17 1.58E-16 5.60E-17 5.98E-17 3.16E-16
12 8.86E-06 1.71E-05 1.52E-04 0.00E+00 0.00E+00 0.00E+00 8.86E-06 1.71E-05 1.52E-04
13 7.26E-11 2.00E-10 2.78E-09 6.86E-17 1.12E-16 4.43E-16 7.26E-11 2.00E-10 2.78E-09
14 4.83E-12 1.63E-11 2.57E-10 2.23E-19 4.98E-18 1.11E-16 4.83E-12 1.63E-11 2.57E-10
15 8.60E-04 3.71E-03 7.43E-02 2.66E-15 3.48E-15 2.12E-14 8.60E-04 3.71E-03 7.43E-02
16 4.17E-11 1.29E-10 2.34E-09 1.10E-16 1.53E-16 4.84E-16 4.17E-11 1.29E-10 2.34E-09

Friday, 04 September 2015 31

Dynare’s internals: Testing the accuracy of Dynare

Optimal transformations for accuracy

• Our transformation appears to have decreased the accuracy of the Euler equation
and the Taylor rule.
• The nominal interest rate is the obvious suspect.
• In hindsight, it is unsurprising that the ‫ ↦ݔ‬log ‫ ݔ‬െ 1 transformation reduced
accuracy.
• The Taylor rule is log-linear when the ZLB does not bind.
• With this transformation, it becomes highly non-linear.
• Imposing the bound this way is not worth the accuracy cost away from the
bound.
• OBC cannot be well approximated by smooth functions!
• Luckily the OBC toolkit is designed to impose OBC in a way that does
preserve accuracy. You will learn more in the OBC section later in the
course.
• If we remove the OBC (or ignore it), how should we modify NKTrans4.mod to
increase its accuracy?
• Can you see any other changes we could make to increase accuracy (and
speed!)?

Friday, 04 September 2015 32

16
 9/4/2015

Dynare’s internals: Testing the accuracy of Dynare

Accuracy comparison of the improved transformed and original untransformed models

Table 3.2: Comparison of the accuracy of NKAccuracy2 and NKTrans5Accuracy.mod

Original Original model errors Transformed model errors Improvement in errors
equation M ean Root mean M aximum M ean Root mean M aximum M ean Root mean M aximum
number absolute squared absolute absolute squared absolute absolute squared absolute
1 8.01E-05 1.03E-04 4.55E-04 1.09E-04 1.56E-04 1.10E-03 -2.91E-05 -5.31E-05 -6.47E-04
2 1.32E-05 3.12E-05 4.75E-04 0.00E+00 0.00E+00 0.00E+00 1.32E-05 3.12E-05 4.75E-04
3 4.21E-06 7.97E-06 7.76E-05 0.00E+00 0.00E+00 0.00E+00 4.21E-06 7.97E-06 7.76E-05
4 2.26E-16 2.45E-16 5.36E-16 4.44E-17 7.61E-17 2.18E-16 1.82E-16 1.69E-16 3.18E-16
5 9.76E-04 1.38E-03 1.15E-02 5.80E-04 7.34E-04 2.69E-03 3.96E-04 6.49E-04 8.76E-03
6 7.53E-04 1.09E-03 9.94E-03 4.41E-04 5.61E-04 2.38E-03 3.12E-04 5.32E-04 7.56E-03
7 2.26E-06 4.27E-06 3.28E-05 0.00E+00 0.00E+00 0.00E+00 2.26E-06 4.27E-06 3.28E-05
8 2.33E-06 4.31E-06 3.99E-05 0.00E+00 0.00E+00 0.00E+00 2.33E-06 4.31E-06 3.99E-05
9 4.61E-04 7.88E-04 8.07E-03 2.30E-17 5.21E-17 2.22E-16 4.61E-04 7.88E-04 8.07E-03
10 6.71E-04 1.14E-03 1.15E-02 1.09E-04 1.90E-04 1.94E-03 5.62E-04 9.50E-04 9.55E-03
11 5.46E-17 9.24E-17 3.16E-16 2.03E-17 5.59E-17 1.58E-16 3.43E-17 3.65E-17 1.58E-16
12 8.86E-06 1.71E-05 1.52E-04 0.00E+00 0.00E+00 0.00E+00 8.86E-06 1.71E-05 1.52E-04
13 7.26E-11 2.00E-10 2.78E-09 7.86E-16 1.86E-15 1.72E-14 7.26E-11 2.00E-10 2.78E-09
14 4.83E-12 1.63E-11 2.57E-10 0.00E+00 0.00E+00 0.00E+00 4.83E-12 1.63E-11 2.57E-10
15 8.60E-04 3.71E-03 7.43E-02 2.61E-15 3.38E-15 1.58E-14 8.60E-04 3.71E-03 7.43E-02
16 4.17E-11 1.29E-10 2.34E-09 1.07E-16 1.52E-16 4.83E-16 4.17E-11 1.29E-10 2.34E-09

Friday, 04 September 2015 33

17