Michel,
2) I agree, many thanks.
3) In dynare++, I have a simple solution for this. I break all the non-linear equations to linear function of non-linear terms, and all this irreducible non-linear terms if they have t+2 and further, I make a new variables and substitute. The transformed system can be read in the .dump file, which is actually a model file. So testing could proceed as follows: a) the model is run in dynare++, b) the model is run in dynare, c) the dump file is run in dynare, d) compare results between b and c, e) check manually that the dump file is equivalent to the original model. If e is true, and b and c different, then there is something wrong in dynare.
4) Yes, it should be. The dynare_simul mex does not care what is the steady state in mat4 file, it just assumes that the decision rule is expressed in deviations from the provided vector. It also does not assume that the constant term is zero. So it will seamlessly work for centralized and non-centralized rules. (At least in theory). Any differences, if i am right, should be attributed to rounding errors, which are likely to be larger for non-centralized rule.
Ondra K.
On Thu, Sep 3, 2009 at 9:35 PM, Michel Juillard michel.juillard@ens.frwrote:
Hi Ondra,
- I committed a few changes to dynare++ brought about the George's work on
package k_order as a DLL for Dynare Matlab
- earlier in the Spring I added an option to set qz_criterium in order to
the user to be able to put it slightly above 1 if the model contains unit roots (as in Dynare Matlab). It is at that time that I added by mistake the printing of D and E that you removed today. Sorry about that.
- today I added a comment concerning dr_centralize and added a function to
be able to write a TwoDMatrix to memory is order to be able to pass results back to the calling program 2) In order to facilitate building k_order DLL, we would like to merge dynare++ and dynare, keeping the same directory architecture. Sebastien would then build an autoconf/configure set of files for compiling both standalone dynare++ and k_order DLL and we would produce binaries for standalone dynare++ at the same time as the other binaries of dynare. Would you agree to that? 3) I observed that for leads on more than 1 period, dynare++ and dynare don't provide the same 2nd order approximation. We should investigate the origin of the difference 4) Is your simulate DLL compatible with dr_centralize option?
All the best,
Michel