As a consequence, a new “block_decomposed” option of the bytecode MEX has been
introduced to explicitly select the block-decomposed version.
Note that we do not always use the “block_decomposed” option even when the
“block” option has been passed to the user, in situations where the block
decomposition brings nothing (e.g. when evaluating the residuals of the whole
model).
A move to fixed format was erroneously made in
4893f0e82c and
ff85fc6489, where stream formatting of floating
points has been replaced by the use of std::to_string().
Use an iterator wrapped inside std::optional instead of a possibly-singular
iterator, because the latter has undefined behaviour.
By the way, pass arguments by const reference.
In particular, no longer rely on a duplicate implementation of the evaluator to
locate where the NaN or Inf is produced. Rather directly pass the pointer to
the faulty operator.
Class Evaluate had data members with the same name as members of
ErrorMsg (which it derives from). In practice, this means that the data members
from ErrorMsg could be unitialized when displaying error messages.
Previously, LBJ was available:
– under stack_solve_algo=6 when neither block nor bytecode were present
– under stack_solve_algo=1 with either block or bytecode (but the documentation
was not making it clear that it was LBJ)
This commit merges the two values for the option, and makes them
interchangeable. LBJ should now be invoked with stack_solve_algo=1 (but
stack_solve_algo=6 is kept for compatibility, and is a synonymous).
The variable “gap” is compared to zero, so the intent probably was that it
could be negative. But size_t is an unsigned type. Rather use a signed type.
There was no user interface, and the feature that it provides has lost
relevance over time.
Note that algorithms for block and/or bytecode still internally use some
equivalent of this parameter, but its initial value will no longer be
modifiable (which could lead to bugs, see commit
e49e7e906f).
When solving a “Solve two boundarise” block with stack_solve_algo=4, the
“slowc” variable is modified. This would affect the resolution of further
“solve backward/forward” blocks, which would yield results.
The fix consists in saving and restoring “slowc”.
Only one iteration is performed on linear blocks. But in the case of
stack_solve_algo=4 it is not enough, since it will not find the right optimal
path lenght at the first iteration (even though that optimal path length is
ufnitary).
– Temporary terms were not correctly passed between blocks
– solve_algo ⩾ 9 was incorrectly passed through bytecode own’s solver instead
of through dynare_solve
Sébastien Villemot