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.
By default, the preprocessor substitutes logs and diffs by auxiliary variables
only in equations of auxiliary models (VAR, PAC). Hence they are not
substituted in the equation defining the target, since it is outside the
auxiliary model.
The fix consists in doing the substitution in that equation as well, when we
parse the linear combination within that equation.
Ref. dynare#1837
The existing check (in AbstractEstimatedParamsStatement::commonCheckPass()) was
only working inside a given estimated_params block, but not across blocks.
This option provides the same behaviour as before the change in
60ef6bbdbd.
It is typically useful when doing several estimations in the same .mod file.
The purpose of this statement is to specify the options that apply to the whole
model, when there are several “model” blocks, so as to restore the symmetry
between those blocks (since otherwise one “model” block would typically bear
the options, while the other ones would typically have no option).
It still remains possible to specify the options on one “model” block, or even
spread accross several ones.
Closes: #19
In a model with [static]/[dynamic] equations, if the user was using include_eqs
with a list of equations that does *not* contain equations marked
[static]/[dynamic], then the call to ModelTree::includeExcludeEquations(…,
static_equations=true) would have an empty list of equation tags (as stored
in tag_eqns).
The right behaviour in this case is to exclude all static equations. However,
the code would exclude none, and this would disrupt the equilibrium between
[static] and [dynamic] equations (since all [dynamic] equations were excluded
by the other call to the same method).
The fix consists in removing the shortcut that returns from the method if
tag_eqns is empty.
Sébastien Villemot
Stéphane Adjemian (Charybdis)