Dynare distinguishes between two types of mathematical expressions: those that are used to describe the model, and those that are used outside the model block (e.g. for initializing parameters or variables, or as command options). In this manual, those two types of expressions are respectively denoted by MODEL_EXPRESSION
and EXPRESSION
.
Unlike Matlab® or Octave expressions, Dynare expressions are necessarily scalar ones: they cannot contain matrices or evaluate to matrices[1].
Expressions can be constructed using integers (INTEGER
), floating point numbers (DOUBLE
), parameter names (PARAMETER_NAME
), variable names (VARIABLE_NAME
), operators and functions.
Parameters and variables can be introduced in expressions by simply typing their names. The semantics of parameters and variables is quite different whether they are used inside or outside the model block.
Parameters used inside the model refer to the value given through parameter initialization or homotopy_setup when doing a simulation, or are the estimated variables when doing an estimation.
Variables used in a MODEL_EXPRESSION
denote current period values when neither a lead or a lag is given. A lead or a lag can be given by enclosing an integer between parenthesis just after the variable name: a positive integer means a lead, a negative one means a lag. Leads or lags of more than one period are allowed. For example, if c
is an endogenous variable, then c(+1)
is the variable one period ahead, and c(-2)
is the variable two periods before.
When specifying the leads and lags of endogenous variables, it is important to respect the following convention: in Dynare, the timing of a variable reflects when that variable is decided. A control variable - which by definition is decided in the current period - must have no lead. A predetermined variable - which by definition has been decided in a previous period - must have a lag. A consequence of this is that all stock variables must use the "stock at the end of the period" convention. Please refer to Mancini-Griffoli (2007) for more details and concrete examples.
Leads and lags are primarily used for endogenous variables. They can be used for exogenous variables under some conditions (TO BE EXPLICITED). They are forbidden for parameters and for local model variables (see model).
When used in an expression outside the model block, a parameter or a variable simply refers to the last value given to that variable. More precisely, for a parameter it refers to the value given in the corresponding parameter initialization; for an endogenous or exogenous variable, it refers to the value given in the most recent initval or endval block.
The following operators are allowed in both MODEL_EXPRESSION
and EXPRESSION
:
binary arithmetic operators: +
, -
, *
, /
, ^
unary arithmetic operators: +
, -
binary comparison operators (which evaluate to either 0
or 1
): <
, >
, <=
, >=
, ==
, !=
The following standard functions are allowed in both MODEL_EXPRESSION
and EXPRESSION
:
exponential: exp(
x
)
natural logarithm: log(
(or equivalently x
)ln(
)x
)
base 10 logarithm: log10(
x
)
square root: sqrt(
x
)
trigonometric functions: sin(
, x
)cos(
, x
)tan(
, x
)asin(
, x
)acos(
, x
)atan(
x
)
maximum and minimum: max(
, a
, b
)min(
a
, b
)
gaussian cumulative distribution function: normcdf(
(note that x
, μ
, σ
)normcdf(
is equivalent to x
)normcdf(
)x
, 0, 1)
In a MODEL_EXPRESSION
, no other function is allowed.[2]
In an EXPRESSION
, it is possible to use any arbitrary Matlab® or Octave function, provided that this function has scalar arguments and return value.
[1] Note that arbitrary Matlab® or Octave expressions can be put in a .mod
file, but those expressions have to be on separate lines, generally at the end of the file for post-processing purposes. They are not interpreted by Dynare, and are simply passed on unmodified to Matlab® or Octave. Those constructions are not addresses in this section.
[2] This is due to the fact that the Dynare preprocessor performs a symbolical derivation of all model equations, and therefore needs to know the analytical derivatives of all the equations in the model equations. In the future, we should add support for other usual functions, and implement an interface to let the user define custom functions, for which he would provide the analytical derivatives.