Automatically detected using clang-tidy with bugprone-reserved-identifier
check.
By the way, homogeneize the define identifiers in relation to camel case
convention.
Those models do not have as many variables as equations, and this case is not
supported by bytecode.
The present commit is an improvement over commit
a8ea57dd63, which had already removed bytecode
for the planner objective model.
The preprocessor would try to write bytecode for the planner objective. But
bytecode only works when there are as many endogenous as equations, which is
not the case for the PlannerObjective object derived from StaticModel.
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
It was erroneously using MATLAB costs, leading to possible
inefficiencies (though those cost tables are probably not very accurate and
should be revised).
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.
As a consequence, and as a temporary measure, always output the
non-block-decomposed legacy representation.
Also drop the block kalman filter output, and drop now useless variables in
M_.block_structure.
The new representation is only supported for MATLAB/Octave, C and Julia output
for the time being. Bytecode and JSON are unsupported.
This commit adds new fields in M_.
This is a preliminary step for dynare#1859.
– DataTree::packageDir() now takes a std::string_view, returns a
std::filesystem::path, and no longer creates that directory
– DataTree::writeToFileIfModified() now takes a std::filesystem::path as
argument
– Do not call DataTree::writeToFileIfModified() for generating MATLAB/Octave
files, since it does not work (the directory inside which the file is written
has been deleted by the preprocessor just before)
– Consistently use DataTree::packageDir() everywhere (for compatibility with
planner_objective)
This is unsafe since the find() method can return a past-the-end iterator,
which should be tested for.
Replace most instances by calls to the std::map::at() method (which throws if
the key is unknown), and which is incidentally more readable.
When computing the derivatives or block decomposition of the planner objective,
the epilogue or the original Ramsey model, the preprocessor would talk about
dynamic/static model, which was confusing. It now uses the right terminology.
If block decomposition fails, error out if “block” option was passed, but not
otherwise.
This commit does not modify the generated files.
This is a preliminary step for dynare#1859.
Compute temporary terms for derivatives of “evaluate” mode, even though those
derivatives are not computed. This is because the temporary terms may be useful
for subsequent blocks.
By the way, add an explanatory comment for the equivalent code in dynamic file.
– factorize common code between the static and the dynamic version
– reorganise language-specific code into dedicated functions
– use a function template in the main helper to do some computations
at compile-time (using constexpr features)
And, symmetrically, when the “bytecode” option is requested by the user, always
create the .m static/dynamic files.
The “bytecode” option therefore no longer modifies the preprocessor output.
We follow the advice given by Josuttis in his book about move semantics.
Deleting those member fuctions can be a bug if we want to allow copy semantics,
because overload resolution will no longer fallback to the copy
constructor/assignment operator when given an rvalue.
In particular, this explain why it was not possible to delete the move
assignment operator of the StaticModel class.
Sébastien Villemot
MichelJuillard