– a generic one: CommonEnums.hh
– and a bytecode-specific one: Bytecode.hh
By the way, rename global constant “near_zero” into “power_deriv_near_zero”,
for clarity.
In particular, use this feature in many loops which feature a special treatment
for the first iteration, using a boolean variable (replacing iterator
manipulation). By the way, also use std::exchange() to simultaneously test the
value of this variable and update it.
– Indicate whether we are trying to normalize the static or dynamic model
– If failed to normalize the static model, suggest to use the “no_static”
option
– Remove a superfluous error message
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.
Consequently drop “occbin” option to “model”.
Incidentally, allow more values in equation tag names (previously some keywords
such as “alpha” were disallowed).
Ref. #68
For the time being, the preprocessor will refuse that this option be used with
any command other than estimation.
By the way, remove occbin_likelihood and occbin_smoother options to estimation.
Ref. dynare#569
— drop Windows 32-bit support
— drop -fno-omit-frame-pointer compilation flag under GNU/Linux
— drop -static-libstdc++ flag under Windows
— no longer link to -lstdc++ under GNU/Linux and macOS
— gracefully fail when 'mexext' value is unknown
— fix segfault due to bad handling of iterators while erasing elements of a set
— fix logic for excluding endogenous variable when it is present on the LHS
Some evaluated blocks could be incorrectly merged, leading to wrong
results (e.g. blocks incorrectly marked as evaluable forward).
Bug introduced in 39407083be
This is inconsistent with the way they are printed in equations (without
underscores).
The practice of appending underscores only makes sense in a MATLAB workspace context.
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.