Initialization of the perfect foresight solver (in extended path) with
the solution of the first order approximation of the model was broken.
If the value of options_.ep.init is "true"" (1) then the solution of the
first order approximation is used as an initial guess for the newton
lilke solver. If the value of options_.ep.init is "false" (0) the solver
is initialized with the steady state.
The second outputr returned by perfect_foresight_solver_core is the
max. abs. residual, not a dummy variable indicating success or failure
of the perfect foresight solver.
Test that the extended path and stoch_simul (with order equal to 1)
algorithms return the same paths for the endogenous variables if the
RE model is linear.
Takes a path for the endogenous variables and returns the residuals of
the dynamic equations. This routine is useful for solving the model with
the PEA approach.
The third input argument of extended_path Matlab/Octave's routine is the
sequence of shocks (T*n array, where n is the number of exogenous
variables and T is the size of the sample). If the third argument is
empty, the (stochastic) extended path is run with gaussian
innovations (this corresponds to the previous behaviour).
TODO:
- Fix the compatibility with ep.replic_nbr
- Check the 'calibrated' mode.
Simulation of the Smets and Wouters perfect foresight model, with a
productivity shock such that the nominal interest rate hits the
ZLB. Comparison of the solutions returned by a Newton
algorithm (stack_solve_algo==0) and the LMMCP algorithm. AT the time of
this commit, the results are different... Probably an issue with the
LMMCP algorithm.
Removed some calls to bsxfun which is not optimal on sparse matrices. I
only removed the calls where I identified bottlenecks (with a Smets and
Wouters model), more tests are needed to decide if we have to remove other
occurences of bsxfun on sparse matrices.
- Use a switch-case block.
- Added a warning when the user tries to solve a linear(ized) model
with solve_algo different from 0 (for a linear model).
- Added an error message if the user try to solve a linearized model
with stack_solve_algo=6 (not implemented).
See PR #1102 by spencerlyon2.
size always returns a tuple, and we were comparing to an int. Dispatch restricts these arguments to all be vectors so length works here.
Stéphane Adjemian (Charybdis)
Michel Juillard