Fix perfect_foresight_problem.cc for case without leaded variables

The file contains the error message

mexErrMsgTxt("M_.lead_lag_incidence should be a real dense matrix with 2+M_.maximum_endo_lag rows and M_.endo_nbr columns");

but M_.lead_lag_incidence is 1 + M_.maximum_endo_lag +M_.maximum_endo_lead, not 2+M_.maximum_endo_lag

test4.mod should trigger the issue.

added bug perfect foresight labels

The example that you provides does not trigger the error message in the MEX.

Also matlab/deterministic-simulations/perfect_foresight_solver_core.m uses a specific codepath for purely backward models, that should not call that MEX.

So I’m not sure there is a bug.

On my machine, I get complex value that trigger the use of the mex-file. I am attaching my workspace. You only need to execute the line

residuals = perfect_foresight_problem(yy(:), y0, yT, oo_.exo_simul, M_.params, oo_.steady_state, periods, M_, options_);

perfect_foresight_solver_line_210.mat

The point is that this MEX file is not designed to handle purely backward models. That would require a different algorithm, and we already have routines that do that.

So if for some reason you have a .mod file that calls that MEX with a purely backward model, then we should understand why, and add a trap.

perfect_foresight_solver contains

if ~isreal(oo_.endo_simul(:)) % cannot happen with bytecode or the perfect_foresight_problem DLL

If you enter that part, it will call the MEX-file without any conditioning in the structure of the problem.

Indeed, so I guess we need to special case purely backward, purely forward and static models at this point.

But what is the point of that whole condition? If we fail, try again with the MEX?

It seems that the idea is, if the simulated paths are complex, to take their real part, and then to check whether this real part is actually a solution, by recomputing the residuals. So the MEX is only called for recomputing the stacked residuals, which are returned as the first output argument (though the real purpose of this MEX is to compute the Jacobian of the stacked dynamic problem, returned as its second output argument).

We have a similar issue in perfect_foresight_solver_core, which will also call the MEX to compute the residuals. This in turn is triggered by homotopy of perfect_foresight_solver. How do we want to proceed? Gracefully erroring out?

I think that, in both cases, we should trap the purely forward/backward cases, and then use another code path for computing the residuals (essentially a loop over a call to the dynamic file).

mentioned in commit JohannesPfeifer/dynare@048073b5

mentioned in merge request !2031 (merged)

assigned to @stepan-a

mentioned in commit JohannesPfeifer/dynare@74dc4f81

mentioned in commit JohannesPfeifer/dynare@f7e0b0be

closed with commit 74dc4f81

mentioned in commit d465b613