The computing of the Ramsey steady state relies on the fact that Lagrange
multipliers appear linearly in the system to be solved. Instead of directly
solving for the Lagrange multipliers along with the other variables,
dyn_ramsey_static.m reduces the size of the problem by always computing the
value of the multipliers that minimizes the residuals, given the other
variables (using a minimum norm solution, easy to compute because of the
linearity property). That function thus needs the derivatives of the optimality
FOCs with respect to the multipliers. The problem is that, when multipliers
appear in an auxiliary variable related to a lead/lag, then those derivatives
need to be retrieved by a chain rule derivation, which cannot be easily done
with the regular static file.
This commit implements the creation of a new file,
ramsey_multipliers_static_g1.{m,mex}, that provides exactly the needed
derivatives w.r.t. Lagrange multipliers through chain rule derivation.
Ref. dynare#633, dynare#1119, dynare#1133
This is effectively a revert of commits 1b4f68f934,
32fb90d5f3 and f6f4ea70fb.
This transformation had been introduced in order to fix the computation of the
Ramsey steady state in the case where Lagrange multipliers appeared with a lead
or lag ⩾ 2 (and where thus part of the definition of an auxiliary variable).
But this transformation had introduced bugs in the handling of external
functions which were difficult to tackle.
Moreover, it seems preferable to keep the strict correspondence between the
dynamic and static model, in order to make reasoning about the preprocessor
internals easier (in particular, for this reason this transformation was not
implemented in ModFile::transformPass() but in ModFile::computingPass(), which
was a bit confusing).
A better solution for the Ramsey steady state issue will is implemented in the
descendent of the present commit.
Ref. dynare#633, dynare#1119, dynare#1133
In particular, use this feature in many loops which feature a special treatment
for the first iteration, using a boolean variable (replacing iterator
manipulation). By the way, also use std::exchange() to simultaneously test the
value of this variable and update it.
When an endogenous is declared with “var(log)”, say “y”:
– creates an auxiliary named “LOG_y”
– replaces “y(±l)” everywhere by “exp(LOG_y(±l))”
– adds a new auxiliary equation “y=exp(LOG_y)”
– adds a new definition “LOG_y=log(y)” in set_auxiliary_variables.m and
dynamic_set_auxiliary_series.m files
This option also works in conjunction with “deflator=…”, such as “var(log,
deflator=…)” (the “log” must appear befor “deflator”). There are no provisions
for combining “log” with “log_deflator”, because that would not make much sense
from an economic point of view (amounts to taking the log two times).
Ref. dynare#349
This is a more natural semantics.
Incidentally, this fixes a bug in the variable mapping (M_.mapping) where some
endogenous, appearing in a log() in a VAR or TCM, would not be mentioned (e.g.
in the var-expectations/7/example1.mod test, and many others).
By the way:
– Fix and improve the explanation of the purpose of the orig_symb_id and
orig_lead_lag fields for auxvars
– Factorize the code that prints those fields in MATLAB and JSON output
The logic was flawed in several ways. In particular, the test files
pac/trend-component-{3,10,11}/example1.mod would return A0 and A0star matrices
where the (2,2) element was incorrectly zero.
The case of a diff aux var corresponding to a complex expression was not
correctly handled, and could lead to a value -1 being returned by these
methods.
This field contains a string representation of the expression that the
auxiliary variable replaces.
It is non-empty for all auxiliary variables, except for Lagrange multipliers.
Ref. dynare#773