It applies the approximated policy function to a set of particles, using
Dynare++ routines.
There is support for parallelization, using Dynare++ multithreading
model (itself based on C++11 threads; we don’t use OpenMP because it is
incompatible with MKL). For the time being, default to a single thread. This
should be later refined through empirical testing.
Previously, if Blanchard-Kahn conditions were not satisfied, there was the
possibility an exception about NaN/Inf values in gy/gu was raised *before* the
exception about BK itself, leading to a confusing message. This commits moves
the test for BK before the test for NaN/Inf in gy/gu.
Closes: #674
— Ondra Kamenik has agreed to the relicensing of utils and parser modules to
GPL
— add DynareTeam’s copyright, since we have made a lot of modifications
— add proper copyright notices in all files
Previously there were GeneralMatrix::numRows() and TwoDMatrix::nrows() for doing
the same thing (and same for columns and Const versions).
Merge these two into GeneralMatrix::nrows().
Note that I removed several #define whose purpose was to avoid typing "typename
ctraits<t>::…". Even though this tends to complicates the code, this is
probably safer, especially since the #define was capturing a free variable (t).
As a consequence, the singleton implementation has to be made thread-safe.
Also implement the singleton pattern using a namespace, rather than a static
instance.
There were two implementations of integer exponentiation. Merge them into a new
file under utils/cc/.
By the way, optimize it using exponentiation by squaring.
We now use a initializer list constructor for creating symmetries of the form
$y^n$, $y^n u^m$, $y^nu^m\sigma^k$.
The constructor taking a single integer is used to initialize a symmetry of a
given length.
Similar changes are made to IntSequence.
This behavior is similar to std::vector.
Since the introduction of the --burn option (in Dynare++ shipped with Dynare
4.3.0), the IRFs reported by Dynare++ were wrong.
The IRFs are computed using a generalized IRF method: the result is
the (average) difference between a simulation with shock and a simulation
without shock. The problem was that the two simulations were not using the same
starting point.
Closes#1634
Sébastien Villemot
Houtan Bastani