parent
2a25119bb3
commit
aee39d54ef
|
@ -555,9 +555,9 @@ by the ``dynare`` command.
|
|||
called ``FILENAME_results.mat`` located in the ``MODFILENAME/Output`` folder.
|
||||
If they exist, ``estim_params_``,
|
||||
``bayestopt_``, ``dataset_``, ``oo_recursive_`` and
|
||||
``estimation_info`` are saved in the same file. Note that Matlab
|
||||
by default only allows ``.mat``-files up to 2GB. You can lift this
|
||||
restriction by enabling the ``save -v7.3``-option in
|
||||
``estimation_info`` are saved in the same file. Note that MATLAB
|
||||
by default only allows ``.mat`` files up to 2GB. You can lift this
|
||||
restriction by enabling the ``save -v7.3`` option in
|
||||
``Preferences -> General -> MAT-Files``.
|
||||
|
||||
.. matvar:: M_
|
||||
|
@ -672,7 +672,7 @@ parser would continue processing.
|
|||
|
||||
It is also helpful to keep in mind that any piece of code that does not violate
|
||||
Dynare syntax, but at the same time is not recognized by the parser, is interpreted
|
||||
as native MATLAB code. This code will be directly passed to the ``driver`` script.
|
||||
Investigating ``driver.m`` file then helps with debugging. Such problems most often
|
||||
as native MATLAB code. This code will be directly passed to the driver script.
|
||||
Investigating the ``driver.m`` file then helps with debugging. Such problems most often
|
||||
occur when defined variable or parameter names have been misspelled so that Dynare's
|
||||
parser is unable to recognize them.
|
||||
|
|
|
@ -649,7 +649,7 @@ not in EXPRESSION):
|
|||
The concept of a steady state is ambiguous in a perfect foresight
|
||||
context with permament and potentially anticipated shocks occuring.
|
||||
Dynare will use the contents of ``oo_.steady_state`` as its reference
|
||||
for calls to the ``STEADY_STATE()``-operator. In the presence of
|
||||
for calls to the ``STEADY_STATE()`` operator. In the presence of
|
||||
``endval``, this implies that the terminal state provided by the
|
||||
user is used. This may be a steady state computed by Dynare (if ``endval``
|
||||
is followed by ``steady``) or simply the terminal state provided by the
|
||||
|
@ -974,7 +974,7 @@ The model is declared inside a ``model`` block:
|
|||
can serve different purposes by allowing the user to attach
|
||||
arbitrary informations to each equation and to recover them at
|
||||
runtime. For instance, it is possible to name the equations with a
|
||||
``name``-tag, using a syntax like::
|
||||
``name`` tag, using a syntax like::
|
||||
|
||||
model;
|
||||
|
||||
|
@ -1427,7 +1427,7 @@ variables take the form ``AUX_DIFF_FWRD_i``, and are equal to
|
|||
``x-x(-1)`` for some endogenous variable ``x``.
|
||||
|
||||
Finally, auxiliary variables will arise in the context of employing the
|
||||
``diff``-operator.
|
||||
``diff`` operator.
|
||||
|
||||
Once created, all auxiliary variables are included in the set of
|
||||
endogenous variables. The output of decision rules (see below) is such
|
||||
|
@ -3182,7 +3182,7 @@ using ``steady``. Again, there are two options for doing that:
|
|||
generated by Dynare will be called ``+FILENAME/steadystate.m.``
|
||||
|
||||
* You can write the corresponding MATLAB function by hand. If your
|
||||
MOD-file is called ``FILENAME.mod``, the steady state file must be
|
||||
``.mod`` file is called ``FILENAME.mod``, the steady state file must be
|
||||
called ``FILENAME_steadystate.m``. See
|
||||
``NK_baseline_steadystate.m`` in the examples directory for an
|
||||
example. This option gives a bit more flexibility (loops and
|
||||
|
@ -4508,7 +4508,7 @@ Computing the stochastic solution
|
|||
option is greater than 1, the additional series will not be
|
||||
used for computing the empirical moments but will simply be
|
||||
saved in binary form to the file ``FILENAME_simul`` in the
|
||||
``FILENAME/Output``-folder. Default:
|
||||
``FILENAME/Output`` folder. Default:
|
||||
``1``.
|
||||
|
||||
.. option:: solve_algo = INTEGER
|
||||
|
@ -4988,7 +4988,7 @@ which is described below.
|
|||
(2004)*), which allows to consider inequality constraints on
|
||||
the endogenous variables (such as a ZLB on the nominal interest
|
||||
rate or a model with irreversible investment). For specifying the
|
||||
necessary ``mcp``-tag, see :opt:`lmmcp`.
|
||||
necessary ``mcp`` tag, see :opt:`lmmcp`.
|
||||
|
||||
|
||||
Typology and ordering of variables
|
||||
|
@ -5258,14 +5258,14 @@ All of these elements are discussed in the following.
|
|||
|
||||
name 'STRING'; bind EXPRESSION; [relax EXPRESSION;] [error_bind EXPRESSION;] [error_relax EXPRESSION;]
|
||||
|
||||
``STRING`` is the name of constraint that is used to reference the constraint in ``relax/bind``
|
||||
equation-tags to identify the respective regime (see below). The ``bind``-expresssion is mandatory and defines
|
||||
``STRING`` is the name of constraint that is used to reference the constraint in ``relax`` / ``bind``
|
||||
equation tags to identify the respective regime (see below). The ``bind`` expression is mandatory and defines
|
||||
a logical condition that is evaluated in the baseline/steady state regime to check whether the specified
|
||||
constraint becomes binding. In contrast, the ``relax``-expression is optional and specifies a
|
||||
constraint becomes binding. In contrast, the ``relax`` expression is optional and specifies a
|
||||
logical condition that is evaluated in the binding regime to check whether the regime returns
|
||||
to the baseline/steady state regime. If not specified, Dynare will simply check in the binding
|
||||
regime whether the ``bind``-expression evaluates to false. However, there are cases
|
||||
where the ``bind``-expression cannot be evaluated in the binding regime(s), because
|
||||
regime whether the ``bind`` expression evaluates to false. However, there are cases
|
||||
where the ``bind`` expression cannot be evaluated in the binding regime(s), because
|
||||
the variables involved are constant by definition so that e.g. the value of the Lagrange
|
||||
multiplier on the complementary slackness condition needs to be checked. In these cases,
|
||||
it is necessary to provide an explicit condition that can be evaluated in the binding
|
||||
|
@ -5273,7 +5273,7 @@ All of these elements are discussed in the following.
|
|||
|
||||
Note that the baseline regime denotes the steady state of the model where the economy will
|
||||
settle in the long-run without shocks. For that matter, it may be one where e.g. a borrowing
|
||||
constraint is binding. In that type of setup, the ``bind``-condition is used to specify the
|
||||
constraint is binding. In that type of setup, the ``bind`` condition is used to specify the
|
||||
condition when this borrowing constraint becomes non-binding so that the alternative regime
|
||||
is entered.
|
||||
|
||||
|
@ -5288,7 +5288,7 @@ All of these elements are discussed in the following.
|
|||
model solution. Third, in contrast to the original Occbin replication codes, the
|
||||
variables used in expressions are not automatically demeaned, i.e. they refer to
|
||||
the levels, not deviations from the steady state. To access the steady state
|
||||
level of a variable, the ``STEADY_STATE()``-operator can be used.
|
||||
level of a variable, the ``STEADY_STATE()`` operator can be used.
|
||||
|
||||
Finally, it's worth keeping in mind that for each simulation period, Occbin will check
|
||||
the respective conditions for whether the current regime should be left. Small numerical
|
||||
|
@ -5324,7 +5324,7 @@ All of these elements are discussed in the following.
|
|||
|
||||
The specification of the model equations belonging to the respective regimes is done in the ``model`` block,
|
||||
with equation tags indicating to which regime a particular equation belongs. All equations that differ across
|
||||
regimes must have a ``name``-tag attached to them that allows uniquely identifying different versions of the
|
||||
regimes must have a ``name`` tag attached to them that allows uniquely identifying different versions of the
|
||||
same equation. The name of the constraints specified is then used in conjunction with a ``bind`` or ``relax``
|
||||
tag to indicate to which regime a particular equation belongs. In case of more than one occasionally-binding
|
||||
constraint, if an equation belongs to several regimes (e.g. both constraints binding), the
|
||||
|
@ -5652,7 +5652,7 @@ All of these elements are discussed in the following.
|
|||
occbin_write_regimes (OPTIONS...);
|
||||
|
||||
|br| Write the information on the regime history stored in ``oo_.occbin.simul.regime_history``
|
||||
or ````oo_.occbin.smoother.regime_history`` into an Excel file stored in the ``FILENAME/Output``-folder.
|
||||
or ``oo_.occbin.smoother.regime_history`` into an Excel file stored in the ``FILENAME/Output`` folder.
|
||||
|
||||
*Options*
|
||||
|
||||
|
@ -5663,7 +5663,7 @@ All of these elements are discussed in the following.
|
|||
|
||||
.. option:: filename = FILENAME
|
||||
|
||||
Name of the Excel-file to write. Default: ``FILENAME_occbin_regimes``.
|
||||
Name of the Excel file to write. Default: ``FILENAME_occbin_regimes``.
|
||||
|
||||
.. option:: simul
|
||||
|
||||
|
@ -6398,7 +6398,7 @@ observed variables.
|
|||
achieve an acceptance rate of
|
||||
:ref:`AcceptanceRateTarget<art>`. The resulting scale parameter
|
||||
will be saved into a file named
|
||||
``MODEL_FILENAME_mh_scale.mat`` in the ``FILENAME/Output``-folder.
|
||||
``MODEL_FILENAME_mh_scale.mat`` in the ``FILENAME/Output`` folder.
|
||||
This file can be loaded in
|
||||
subsequent runs via the ``posterior_sampler_options`` option
|
||||
:ref:`scale_file <scale-file>`. Both ``mode_compute=6`` and
|
||||
|
@ -6502,11 +6502,11 @@ observed variables.
|
|||
Name of the file containing previous value for the mode. When
|
||||
computing the mode, Dynare stores the mode (``xparam1``) and
|
||||
the hessian (``hh``, only if ``cova_compute=1``) in a file
|
||||
called ``MODEL_FILENAME_mode.mat`` in the ``FILENAME/Output``-folder.
|
||||
called ``MODEL_FILENAME_mode.mat`` in the ``FILENAME/Output`` folder.
|
||||
After a successful run of
|
||||
the estimation command, the ``mode_file`` will be disabled to
|
||||
prevent other function calls from implicitly using an updated
|
||||
mode-file. Thus, if the ``.mod`` file contains subsequent
|
||||
mode file. Thus, if the ``.mod`` file contains subsequent
|
||||
``estimation`` commands, the ``mode_file`` option, if desired,
|
||||
needs to be specified again.
|
||||
|
||||
|
@ -9019,9 +9019,9 @@ adding prior information comes at the cost of a loss in efficiency of the estima
|
|||
|
||||
``FILENAME``
|
||||
|
||||
The name of the mat-file (extension ``.mat``) containing a
|
||||
The name of the MAT-file (extension ``.mat``) containing a
|
||||
user-specified weighting matrix. The file must include a positive definite
|
||||
square matrix called `weighting_matrix` with both dimensions
|
||||
square matrix called ``weighting_matrix`` with both dimensions
|
||||
equal to the number of orthogonality conditions.
|
||||
|
||||
Default value is ``['DIAGONAL','OPTIMAL']``.
|
||||
|
@ -9138,7 +9138,7 @@ adding prior information comes at the cost of a loss in efficiency of the estima
|
|||
A value of 1 means that the estimation procedure will demean each data
|
||||
series by its empirical mean and each model moment by its theoretical
|
||||
mean. See :opt:`prefilter <prefilter = INTEGER>` for more details.
|
||||
Default: `0`, i.e. no prefiltering.
|
||||
Default: ``0``, i.e. no prefiltering.
|
||||
|
||||
.. option:: logdata
|
||||
|
||||
|
@ -9162,7 +9162,7 @@ adding prior information comes at the cost of a loss in efficiency of the estima
|
|||
.. option:: mode_compute = INTEGER | FUNCTION_NAME
|
||||
|
||||
See :opt:`mode_compute <mode_compute = INTEGER | FUNCTION_NAME>`.
|
||||
Default: ``13``, i.e. ``lsqnonlin`` if the Matlab Optimization Toolbox or
|
||||
Default: ``13``, i.e. ``lsqnonlin`` if the MATLAB Optimization Toolbox or
|
||||
the Octave optim-package are present, ``4``, i.e. ``csminwel`` otherwise.
|
||||
|
||||
.. option:: additional_optimizer_steps = [INTEGER|FUNCTION_NAME,INTEGER|FUNCTION_NAME,...]
|
||||
|
@ -9901,7 +9901,7 @@ Shock Decomposition
|
|||
|
||||
.. option:: write_xls
|
||||
|
||||
Saves shock decompositions to Excel-file in the main
|
||||
Saves shock decompositions to Excel file in the main
|
||||
directory, named
|
||||
``FILENAME_shock_decomposition_TYPE_FIG_NAME.xls``. This
|
||||
option requires your system to be configured to be able to
|
||||
|
@ -10110,7 +10110,7 @@ Shock Decomposition
|
|||
|
||||
.. option:: write_xls
|
||||
|
||||
Saves shock decompositions to Excel-file in the main
|
||||
Saves shock decompositions to Excel file in the main
|
||||
directory, named
|
||||
``FILENAME_shock_decomposition_TYPE_FIG_NAME_initval.xls``. This
|
||||
option requires your system to be configured to be able to
|
||||
|
@ -13502,7 +13502,7 @@ a trend target to which the endogenous variables may be attracted in the long-ru
|
|||
.. option:: model_name = STRING
|
||||
|
||||
Name of the VAR model, which will be referenced in ``var_expectation_model`` or ``pac_model``
|
||||
as an `auxiliary_model`. Needs to be a valid Matlab field name.
|
||||
as an ``auxiliary_model``. Needs to be a valid MATLAB field name.
|
||||
|
||||
.. option:: eqtags = [QUOTED_STRING[, QUOTED_STRING[, ...]]]
|
||||
|
||||
|
@ -13600,7 +13600,7 @@ a trend target to which the endogenous variables may be attracted in the long-ru
|
|||
.. option:: model_name = STRING
|
||||
|
||||
Name of the trend component model, will be referenced in ``var_expectation_model``
|
||||
or ``pac_model`` as an `auxiliary_model`. Needs to be a valid Matlab field name.
|
||||
or ``pac_model`` as an ``auxiliary_model``. Needs to be a valid MATLAB field name.
|
||||
|
||||
.. option:: eqtags = [QUOTED_STRING[, QUOTED_STRING[, ...]]]
|
||||
|
||||
|
@ -13746,16 +13746,16 @@ More generally, it is possible to consider finite discounted sums.
|
|||
|
||||
.. matcomm:: var_expectation.initialize(NAME_OF_VAR_EXPECTATION_MODEL);
|
||||
|
||||
|br| Initialise the `var_expectation_model` by building the companion matrix
|
||||
of the associated auxiliary `var_model`. Needs to be executed before attempts to simulate or
|
||||
|br| Initialise the ``var_expectation_model`` by building the companion matrix
|
||||
of the associated auxiliary ``var_model``. Needs to be executed before attempts to simulate or
|
||||
estimate the model.
|
||||
|
||||
|br|
|
||||
|
||||
.. matcomm:: var_expectation.update(NAME_OF_VAR_EXPECTATION_MODEL);
|
||||
|
||||
|br| Update/compute the reduced form parameters of `var_expectation_model`. Needs to be executed
|
||||
before attempts to simulate or estimate the model and requires the auxiliary `var_model` to have
|
||||
|br| Update/compute the reduced form parameters of ``var_expectation_model``. Needs to be executed
|
||||
before attempts to simulate or estimate the model and requires the auxiliary ``var_model`` to have
|
||||
previously been initialized.
|
||||
|
||||
|br|
|
||||
|
@ -13769,9 +13769,9 @@ More generally, it is possible to consider finite discounted sums.
|
|||
|
||||
var_expectation.update('varexp');
|
||||
|
||||
.. warning:: Changes to the parameters of the underlying auxiliary `var_model` require calls to
|
||||
`var_expectation.initialize` and `var_expectation.update` to become effective. Changes to the
|
||||
`var_expectation_model` or its associated parameters require a call to `var_expectation.update`.
|
||||
.. warning:: Changes to the parameters of the underlying auxiliary ``var_model`` require calls to
|
||||
``var_expectation.initialize`` and ``var_expectation.update`` to become effective. Changes to the
|
||||
``var_expectation_model`` or its associated parameters require a call to ``var_expectation.update``.
|
||||
|
||||
PAC equation
|
||||
------------
|
||||
|
@ -13839,7 +13839,7 @@ simply add the exogenous variables to the PAC equation (without the weight
|
|||
|
||||
.. command:: pac_model (OPTIONS...);
|
||||
|
||||
|br| Declares a PAC model. A `.mod` file can have more than one PAC model or PAC equation, but each PAC equation must be associated to a different PAC model.
|
||||
|br| Declares a PAC model. A ``.mod`` file can have more than one PAC model or PAC equation, but each PAC equation must be associated to a different PAC model.
|
||||
|
||||
*Options*
|
||||
|
||||
|
@ -13950,8 +13950,8 @@ of the PAC equation can only be conducted conditional on the values of the param
|
|||
of the auxiliary model.
|
||||
|
||||
.. warning:: The estimation routines described below require the option
|
||||
`json=compute` be passed to the preprocessor (via the command line
|
||||
or at the top of the `.mod` file, see :ref:`dyn-invoc`).
|
||||
``json=compute`` be passed to the preprocessor (via the command line
|
||||
or at the top of the ``.mod`` file, see :ref:`dyn-invoc`).
|
||||
|
||||
|
||||
.. matcomm:: pac.estimate.nls(EQNAME, GUESS, DATA, RANGE[, ALGO]);
|
||||
|
@ -14010,7 +14010,7 @@ of the auxiliary model.
|
|||
.. warning:: The specification of `GUESS` and `DATA` involves the use of structures.
|
||||
As such, their subfields will not be cleared across Dynare runs as the structures
|
||||
stay in the workspace. Be careful to clear these structures from the memory
|
||||
(e.g. within the mod-file) when e.g. changing which parameters are calibrated.
|
||||
(e.g. within the ``.mod`` file) when e.g. changing which parameters are calibrated.
|
||||
|
||||
Displaying and saving results
|
||||
=============================
|
||||
|
|
Loading…
Reference in New Issue