Due to a limitation of the current implementation, this breaks syntaxes like
[ (i,j) ] (but not [ (2,j) ]; the problem only occurs when an array is
constructed by specifying as first element a tuple whose first element is a
variable name). Solving this problem requires an overhaul of the
macro-processor, with construction of ASTs at parsing time, and evaluation
later on (instead of doing on-the-fly evaluation).
Ref #5
- 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
- == and != have now lower priority than <= < >= >, for consistency with the
Dynare modelling language (and incidentally C and C++, but not Julia).
- ^ has now higher priority and no associativity, for consistency with the
Dynare modelling language (and usual arithmetic notation).
- & has now higher priority than |, and both have lower priority than + and -,
but higher than inequality comparators. This is not the same as C and C++ (in
which & and | are just above && and ||), but this allows for expressions such
as "a|b == c" to have their most natural semantics (i.e. this will compare
the union of a and b with c; the C/C++ priority level would have resulted in
a type error).
Ref #5.
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.
We can therefore manipulate objects by value rather than by pointers, which
saves a lot of memory manipulations (and avoid potential segfaults and memory
leaks).
Note that there is no default action ("$$ = $1") when using the variant type,
so we add them explicitly.
- store objects whose persistence is not guaranteed (e.g. strings) as values
instead of references (to avoid possible segfaults)
- on the contrary, always store the SymbolTable as a reference, since its
persistence is guaranteed, and we don't want to copy it
- use pass-by-value in constructors whenever possible
- remove useless const keyword when passing by value
aux_equations only contain the definition of auxiliary variables, and
may diverge from those in the main model (equations), if other model
transformations applied subsequently. This is not a problem, since
aux_equations is only used for regenerating the values of auxiliaries
given the others.
For example, such a divergence appears when there is an expectation
operator in a ramsey model, see
tests/optimal_policy/nk_ramsey_expectation.mod */
This table serves no useful purpose. It is better to append auxiliary equations
at the time they are created, to avoid messing with the recursive ordering.
Ensure that all diff operators appear once with their argument at current
period (i.e. maxLag=0).
If it is not the case, generate the corresponding expressions.
This is necessary to avoid lags of more than one in the auxiliary
equation, which would then be modified by subsequent transformations
(removing lags > 1), which in turn would break the recursive ordering
of auxiliary equations.
See McModelTeam/McModelProject/issues/95 for an example.
- use std::unique_ptr for MacroDriver::lexer
- use std::shared_ptr for MacroValue objects constructed by the parser
This is made possible using Bison 3.0 variant value type.
Using non-pointer type is not possible since MacroValue is polymorphic.
Using std::unique_ptr is not possible since the value type must be
copyable (see
https://lists.gnu.org/archive/html/bug-bison/2015-03/msg00004.html).
Define a new type MacroValuePtr == shared_ptr<const MacroValue> for code
clarity.
Use the following convention for shared_ptr arguments to functions:
+ if pass-by-value, means that the callee acquires ownership
+ if pass-by-const-reference, the callee does not acquire ownership
- naked pointers are still used for tracking the filename in Bison's location
type, since we don't have control over that
Also, by the way:
- arrays can now contain elements of any type
- simplify MacroDriver::loop_stack using std::tuple
- toArray() method now fails on function objects
- no need to use const qualifiers, since all MacroValue objects are immutable
- use an exception for detecting division by zero
There is no reason to associate an exogenous variable or parameter to a
specific equation. For these types the user can use the pipe
notation (|x, |p) in any equations or the usual parameters and varexo statements.