The implementation no longer relies on ramsey_policy.m at the MATLAB/Octave
level.
By the way, drop ModFileStructure::ramsey_model_present, which is now
redundant.
Options “order”, “partial_information” and “k_order_solver” are not accepted by
the command (this code is probably a remnant of the deprecated “ramsey_policy”
command).
– M_.ramsey_orig_endo_nbr is the number of endogenous variables in the model
present just before adding the Lagrange multipliers and computing the Ramsey
FOC; it is by construction equal to the number of equations that will be added
by the process of computing the FOCs
– M_.ramsey_orig_eq_nbr is the number of equations in the model present just
before adding the Lagrange multipliers and computing the Ramsey FOC; it is by
construction equal to the number of Lagrange multipliers that will be added by
the process of computing the FOCs
Note that both may be greater than the number of endogenous/equations written
by the user, because some auxiliary variables may have already been added.
Also note that the number of policy instruments in M_.ramsey_orig_endo_nbr −
M_.ramsey_orig_eq_nbr
As a consequence, drop M_.ramsey_eq_nbr (which was actually equal to
M_.ramsey_orig_endo_nbr) and M_.orig_eq_nbr (which was actually equal to
M_.ramsey_orig_eq_nbr, but would also be set in the non-Ramsey case). The new
names are clearer.
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
If a given external function was called two times with different arguments,
then the second call would always be computed in the same temporary terms
chunk (derivation order or block) as the first call, even if this was not
necessary (technically, the second call would be promoted in the temporary
terms computation in the same category as the first call).
This could possibly lead to an inefficiency.
If an endogenous with a lead ⩾ 2 or an exogenous with a lead ⩾ 1 appeared in
the argument(s) of a call to an external function, the auxiliary variable
transformation was incorrect (the variable was replaced inside the function
call, while it is the whole function call that has to be replaced).
This could lead to incorrect results in stochastic contexts, when the external
function is nonlinear.
The first argument to ExprNode::computeTemporaryTerms() is supposed to be a
pair (endo derivation order, param derivation order). The two elements were
interverted in the call. This would not affect the result, because parameter
derivatives are not computed there and what matters is the lexical ordering
which remains the same. But fixing the order is better, for consistency with
the method description.
It was erroneously using MATLAB costs, leading to possible
inefficiencies (though those cost tables are probably not very accurate and
should be revised).
The argument had the same name as the data member “datatree”, so this could
lead to confusion (though there was no bug, since the argument was masking
the data member).
Previously, the MinGW location was appended multiple times to the PATH
variable, which in some cases would make the variable too long and thus
dysfunctional.
The variable is now initialized once when the worker threads are created.
By the way, move the macOS+Octave environment variable initializations to the
same place, for consistency.
Variable indices would be incorrect in the evaluated Jacobian if recursive
variables were present. This would lead to incorrect results and/or crashes in
bytecode MEX. This bug has been exposed by commit
f45a99fc68, which actually enabled mfs>0 for
static models.
Commit 23b0c12d8e introduced caching in chain
rule derivation (used by block decomposition), which increased speed for mfs >
0, but actually decreased it for mfs=0.
This patch introduces the pre-computation of derivatives which are known to be
zero using symbolic a priori (similarly to what is done in the non-chain rule
context). The algorithms are now identical between the two contexts (both
symbolic a priori + caching), the difference being that in the chain rule
context, the symbolic a priori and the cache are not stored within the ExprNode
class, since they depend on the list of recursive variables.
This patch brings a significant performant improvement for all values of the
“mfs” option (the improvement is greater for small values of “mfs”).
Input and output ranges should not overlap when calling std::set_union(),
otherwise the behaviour is undefined.
It seems that in this precise case the computation would still be
correct (though inefficient), because of the properties of std::set or because
of the specific implementation in libstdc++. But it’s better to be on the safe
side.
In a dynamic context, the only potentially non-null derivatives of
STEADY_STATE(…) are the parameters. We know that the derivatives w.r.t. other
variables are zero, so store that information in non_null_derivatives.
- drop the Julia stuff, since it is no longer used
In particular, no longer use static linking, since builds are now only
for testing purposes and are not shipped
- drop the Windows i686 build, since we no longer support that configuration
- bump Boost version used for Windows x86-64 build
- rename build_linux_aarch64 into build_linux_arm64 for clarity
More precisely, incorrect equation normalization could occur in the presence of
cos, sin, tan, cosh and x^n (where n is an even integer).
Also add some comments explaining why some other rules are (hopefully) correct.
Sébastien Villemot