Playing a bit with the epilogue block, I would suggest the following fixes/enhancements:
epilogue should honor trends defined for variables, so to ensure that leads/lags of variables are equally treated in model and epilogue blocks;
it would be good to store the names of the epilogue variables in M_, for example M_.epilogue_names, so that we can think of allowing post-processing routines to automatically recognize that such a name means something.
Edited
Designs
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
@rattoma By “epilogue should honor trends defined for variables”, I guess that you mean multiplying/dividing by the growth factor for lead/lag variables? How does that interact with the WITH_TREND() operator suggested in dynare#1648 (closed)?
@sebastien I think it is a complementary behavior: here we want to correct (detrended) variables multiplying/dividing by the growth factor for lead/lag variables, whereas WITH_TREND() adds back the trend to the de-trended var. However, the latter should have been already corrected by the growth factor in leads/lags, otherwise adding back the trend would provide the wrong result (assuming to add back everywhere in the equation the trend at time t, whatever the lead/lag).
May I add another couple if items, if too complicated let's postpone to 4.7:
make a static version of the epilogue, which would allow to easily get the steady state of epilogue variables;
tracing the endo names that are needed to evaluate epilogue ones, e.g. via a var_list_ in M_. This would be useful for example to set a list of variables for stoch_simul which would allow to get epilogue ones
@houtanb things look OK except for external functions. The temporary variables storing results from the evaluation of external function should be a dseries object, I think, otherwise I get crashes.
see attached files (I give the example with the static epilogue, for simplicity: the one with _mr extension is the version that I manually hacked that works). qa.m is the external function
@sebastien@houtanb many thanks, I am done with re-build.
I think it useful I keep myself trained with building dynare. I always forget to delete preprocessor/src/DynareFlex.cc ;).
@rattoma you should not need to delete this file. When you compile, the build system will notice if DynareFlex.ll has been modified and thus this file needs to be recreated.
@rattoma your suggestion would have required a slight hack in the preprocessor for the way we treat external functions. Instead, I simply did away with temporary terms for external functions; now they are computed directly in the expression. I think this is actually what we want as the same call to a function with the same arguments could change value in the epilogue block if between calls that variable's value was changed.