Currently Kalman uses its own slightly modified subset of the sylv library imported from Dynare++ that:
a) boosts the General Matrix copy and assignment using memecpy(). with new copy() functions
b) adds new functions to GeneralMatrix a.1.) /* this = this * m^(-1) */ void multInvRight(GeneralMatrix&m);
a.2) /* Returns true if this and m matrices are different for more than tolerance tol */ bool isDiff(const GeneralMatrix& m, const double tol)const; bool isDiffSym(const GeneralMatrix& m, const double tol)const; bool isDiffUpprTriang(const GeneralMatrix& m, const double tol=0.0)const {return isDiffSym(m, tol);}
c) reduces copy-construction by modifying multVec for GeneralMatrix
If we are to use kord and kalman within the same integrated module (estimation), we need to propagate those changes to the main sylv library within Dynare++ (which could itself benefit from some of those modifications too) and use it instead the current needed subset.
Also, it seems that similarly gensylv uses another version of sylv library too but that can stay unchanged, separate for the moment.
Best regards
George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "Ondra Kamenik" ondra.kamenik@gmail.com Cc: "List for Dynare developers" dev@dynare.org Sent: Friday, September 04, 2009 11:37 AM Subject: Re: [DynareDev] dynare++
Hi Ondra,
thanks for the quick answer. We are going to move the dynare++ SVN repository immediately and make the old one read-only, because we can't merge the history of dynare++ with the history of dynare. We will then try to make a new dynare++ binary for Windows before the end of September. We will then work on an autoconf system for dynare++
For leads in t+2, I will follow your suggestion and get back to you.
All the best,
Michel
Ondra Kamenik wrote:
Michel,
I agree, many thanks.
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.
- 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.fr mailto:michel.juillard@ens.fr> wrote:
Hi Ondra, 1) 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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev