Also be more strict on the form of the target (must now be X(-1) or log(X(-1))
where X is *not* an auxiliary variable).
By the way, improve some comments in SymbolTable.
The detection of the target EC variable to be used when constructing the
forward-looking expectation variable is rather fragile.
When the PAC model is written with an (non-)optimizing share of agents,
restrict the identification of the target variable to the optimizing
expression, to minimize the risk of wrong identification.
By the way, add a few comments, and a small simplification.
By default, the preprocessor is supposed to only do the “unary ops”
transformation in the equations of VAR/PAC/trend component models.
However, the implementation was slightly different so far. It would detect
candidates to this transformation in the chosen equations, but it would then
perform the substitution in *all* equations.
This could lead for crashes, for example if the chosen equation contains
log(X(-1)), but another (non-chosen) equation has log(X(-2)). Then this latter
expression, even though it belongs to the same lag-equivalence class, is not
properly handled, causing a segfault.
Also do a few related cosmetic changes.
Rather use a single vector as in non-block mode.
By the way, change the order of output arguments in static functions, to be
closer to the dynamic ones.
Temporary terms need to be computed per equation (as was done previously), and
not simply per block.
It’s necessary to track temporary terms per equation, because some equations
are evaluated instead of solved, and an equation E1 may depend on the value of
an endogenous Y computed by a previously evaluated equation E2; in this case,
if some temporary term TT of equation E2 contains Y, then TT needs to be
computed after E1, but before E2.
In particular, in dynamic models, temporary terms are now computed for
derivatives w.r.t. exogenous, and also w.r.t. endogenous variables that do not
belong to the block.
This was only adding unneeded complexity, for no clear reason (we’re very far
from reaching 2³¹ equations, and if we wanted to support models that large, it
would be better to use long integers to avoid being limited to 2³²).
If a float smaller than one in absolute value is written without a
leading zero in the mod file, for instance as `.5`, we really need to
prefix the number with a zero. The simplest approach is to convert
the strings representing the numerical constants into floats.
The “diff” operator was incorrectly replaced by its argument in the static
model, leading to an incorrect result for the steady state.
This is because the information contained in the “expr_node” field of the
auxiliary variables storage was not consistent across all types of auxiliary
variables: for a “diff()” operator, it would contain the argument of the
operator, instead of the full node. Hence it would not simplify to zero at the
steady state.
A similar inconsistency was also present for the “expectation()” operator,
though it was not leading to an incorrect static model.
In the absence of braces, the last “else” clause is always associated with the
closest “if”, which is not what was intended here. The indentation was
misleading.
Allows for the inclusion/exclusion of a set of equations, specified either on the command line or in a text file.
If the equation has a single endogenous variable on the LHS, then the equation is moved. If not, if the equation has an `endogenous` tag then that variable is removed along with this equation. If not, then an error is thrown.
As a command line argument, `exclude_eqs` can take the form (same syntax for `include_eqs`):
* `exclude_eqs=eq1 to remove all equations declared as `[name=eq1]`
* `exclude_eqs=[eq 1, eq 2]` to remove all equations declared as `[name=eq 1]` or `[name=eq 2]`
* `exclude_eqs=[tagname=X]` to remove all equations declared as `[tagname=X]`
* `exclude_eqs=[tagname=(X, Y)]` to remove all equations declared as `[tagname=X]` or `[tagname=Y]`
When declared in a file, the file should be of the form:
```
eq 1
eq 2
```
to remove all equations declared as `[name=eq 1]` or `[name=eq 2]`.
It should be of the form:
```
tagname=
X
Y
```
to remove all equations declared as `[tagname=X]` or `[tagname=Y]`.
In many cases, they can be replaced by the curly braces syntax.
Otherwise, we can now use the pair() and tuple() constructors, without the need
to specify template parameters, thanks to class template argument
deduction (new in C++17).
This is made possible by the getLagEquivalenceClass() method introduced in the
previous commit.
Previously, the static version of the LHS expressions was used.
As a consequence, drop ModFile::diff_static_model, now useless.
Previously, for testing whether two diff() expressions or two unary ops were
the lead/lag of each other, the preprocessor would test whether they have the
same static representation. This is ok for simple expressions (e.g.
diff(x(-1))), but not for more complex ones (e.g. diff(x-y) and diff(x(-1)-y)
should not be given the same auxiliary variable).
This commit fixes this by properly constructing the equivalence relationship
and choosing a representative within each equivalence class. See the comments
above lag_equivalence_table_t in ExprNode.hh for more details.
Closes#27
Those methods can return a negative value in some cases. For example,
maxLead(x₋₁) = −1.
But constants were always returning a value of zero, which means that we had
inconsistent behaviour like maxLead(x₋₁ + 2) = 0.
This commits fixes the behaviour by making these methods return the smallest
possible integer when called on constants.
The transformation would be incorrect because of the expectation operator.
There was already a safety check, but it was not entirely correct. For example,
if “exp(y)” was appearing before “exp(y(+1))”, the check would not catch the
problem, because it happened after the substitution table had been filled. So
we now do the check before filling that table.
We must provide a return value for
VarExpectationNode::maxLagWithDiffsExpanded().
Return zero, which will lead to the right overall result even if it is not
strictly the right choice (see the comment in the code).
- ExprNode::maxLag() and ExprNode::maxLead() now take into account exogenous
deterministic variables, for consistency with M_.maximum_{lead,lag}
- ExprNode::maxLag() no longer behaves as if diff() operators were
expanded (i.e. it now returns 1 on diff(x(-1))), for consistency with
maxEndoLag() and maxExoLag()
- New ExprNode::maxLagWithDiffsExpanded() method, that behaves as maxLag() used
to behave (except that it also takes exogenous deterministic into account)
Previously, this function was counting the total number of diff() operators in
an expression. But this is not very useful, and is potentially misleading,
because in practice we use this function to compute the maximum lag on
variables in levels.
This function now returns the maximum number of nested diffs.
For example, on diff(x)+diff(diff(y)), this function was returning 3, and it
now returns 2.
The engine is now more robust and should reject any expression that does not
conform to the expected form. It is also able to deal with more cases, such as
terms appearing with a minus sign, or variables in the middle of a
three-factors product.
BTW, use a std::tuple for storing the result of the matching inside
PacExpectationNode, and change the order of components within the
structure (variable first, scalar last).
This facilitates switching variable types on the fly. In particular, this
allows removing the hack in DynamicModel::updateAfterVariableChange() that way
basically recreating all the nodes after the type change.
This was not conceptually an enum, but rather a collection of unrelated
constants:
- two constants for use as placeholder for symbol IDs at different places
- one constant for the default number of arguments
This mimicks the structure of M-functions (though the logic for filling the
temporary terms vector is a bit different).
This change implied a modification in the way we compute the checksum in case
of block decomposition (the temporary terms for the C output are not correctly
computed in that case).
- BTW, store them in a std::vector rather than std::list
- incidentally, fix issue in VariableNode::removeTrendLeadLag where expression
sharing was possibly violated when creating a new VariableNode
Given a previously declared var_model, the var_expectation_model statement is
used to declare a way of forming expectations with this VAR (possibly using a
finite or infinite discounted sum). The var_expectation operator now takes a
single argument, the name of the var_expectation_model.
For the moment, this only works when the var_model is using equations
explicitly declared in the model block.
Sébastien Villemot
Houtan Bastani
Stéphane Adjemian(Charybdis)