Hi George,
thank you for looking into Dynare++ and the resulting analysis. Given our objectives, I suggest that we go for the highest level of integration and use your solution 2.2, keeping in mind the following:
1) I don't understand fully what Ondra is doing for approximation around the stochastic steady state and I don't want to offer it yet in Dynare Matlab. So, for the time beeing we use only steps=0 2) After a first call to Approximation::walkStochSteady(), we need, for estimation, to be able to call repeatedly the first order approximation for different values of the parameters and, possibly different values of the deterministic steady state. As all the arrays (matrices, tensors ....) will have the same size in each interation, we need to factorize memory allocation is this case and only replace the values in existing arrays. This may require far reaching changes in the existing code. 3) For the deterministic steady state, we need to implement three variants: a) the exact steady state values are supplied by the user (then the steady state isn't affected by estimated parameters) b) the steady state is computed by a call to the nonlinear solver in Dynare++ (or we may substitute the nonlinear solver of GSL or yet another one) c) the steady state is obtained from a function supplied by the user. This function can be a *.m file (as currently the *_steadystate.m file) or a DLL when we integrate recursive steadystate computation in the *.mod file. 4) IMHO, the only change necessary to the DLLs created by the preprocessor with the USE_DLL option is to export as well the functions 'Dynamic', and respectively 'Static', and not only the function Mexfunction(). This requires an explicit compilation of the DLL rather than using the 'mex' shell function and a modification of the mex.def file (currently created and deleted by the mex shell function). 5) Currently, dynare++ uses the value 1.0 to discriminate between statble and unstable roots. This creates a problem for models with unit roots (models that are stable around a stochastic growth path). Because of small inaccuracies in the computation of (repeated) unit roots, we need to use a value slightly above one (controlled by option qz_criterium in Dynare Matlab). 6) This is a question. Could you please look whether and how dynare++ eliminates static variables when computing the first order approximation? I changed the way this is done in Dynare Matlab after having worked on dynare++. Currently, I use a QR decomposition of the part of the Jacobian relative to current variables. This only requires that the Jacobian relative to static variables be full column rank. This is a good occasion for me to write the algebra of this part.
All the best,
Michel
-------- Original Message -------- Subject: Re: [DynareDev] [Fwd: Re: AIM in Dynare +PS] Date: Fri, 15 Aug 2008 12:10:58 +0100 From: G. Perendia george@perendia.orangehome.co.uk To: michel.juillard@ens.fr References: 48966576.9060700@ens.fr
Dear Michel
I enclose zipped initial analysis notes (FirstOrderAnalysis.rtf) and UML documentation for the Kord package that may be of some help too. For a better understanding, I included some of Ondra's original, very useful explanations though you may be already familiar with them.
I think that simple no 1.1 FirstOrder solution may be ready in a few weeks. This solution is equivalent to the option (b) discussed earlier:
(b) preprocessor dynamically create a truly dynamically loadable module <mod>_dynamic.DLL callable from Dynare++.DLL in addition to the current <mod>_dynamic.m,,
....
Best regards
George ----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Monday, August 04, 2008 3:12 AM Subject: [DynareDev] [Fwd: Re: AIM in Dynare +PS]
Dear Georges,
thanks for looking into that. My responses are in upper case.
1) Do I understand well that we may be providing an optional alternative, or, poss. a full replacement for the current dr1.m? I.e., the current mjdgges strand solution for 1st order (i.e the 1st part) of dr1.m may optionally or fully be replaced with the new Dynare++ based 1st order solution DLL. Is this aimed to bring a benefit of improved performance and a better starting point for the k-order solution when if needed?
YES, WE WANT TO OFFER THIS OPTION AND USE IT FOR LIKELIHOOD COMPUTATIONS
As I understand so far, we can extend the current Dynare functionality substantially mainly if we extend:
a) the current 2nd order with 2+ (i.e. k>1) order solution, thus, the 2nd part of dr1 by replacing it with the k-order solution DLL based on Dynare++, (either as optional alternative or as a full replacement) and, poss.
AS AN OPTION
b) replace/complement the Ramsey part of DR1 by similar action based on Dynare++ code. Will that change then also include replacing Ramsey planner part of dr1 with the Dynare++ Ramsey?
NO, WE DON'T BRING IN DYNARE++ RAMSEY STUFF
2) Also, for 1st and k-order I think I see some broad-lines of possible integration solutions (but I could be wrong):
A) , one is to run new Dynare++.DLL (Dynare++ without parser and simulation) callable in a flexible manner from Matlab (and Matlab Dynare), and its inputs may be the results of <mod>_dynamic.m run by a wrapping Matlab (.m) shell routine (e.g. a modified dr1.m) which calls both <mod>_dynamic.m, (at least to read the model,) and then Dynare++.DLL , or,
WE DON'T WANT TO USE <MOD>_DYNAMIC.M. MY PREFERRED SOLUTION IS YOUR POINT b)
B) Preprocessor needs to be changed and, either:
a) new Dynare++.DLL becomes attached straight to the current Dynare preprocessor which now creates <mod>_dynamic.m in the first place, or,
I DON'T THINK WE WANT THAT. WE LOSE MATLAB MODULAR APPROACH
b) preprocessor dynamically create a truly dynamically loadable module <mod>_dynamic.DLL callable from Dynare++.DLL in addition to the current <mod>_dynamic.m, or,
THIS EXISTS ALREADY AND IT IS WHAT WE WANT TO USE. IT IS TRIGGERED BY OPTION USE_DLL IN model KEYWORD.
c) preprocessor dynamically create a modified (new) <mod>_dynamic.m which has a built-in call to dynamically loadable module Dynare++.DLL. The modified (new) <mod>_dynamic.m will be callable from Matlab Dynare alike the current <mod>_dynamic.m (e.g. from modified dr1.m) but with extra, k-order Taylor params being returned.
THIS IS TOO COMPLICATED AND b) IS SIMPLER
Please let me know what you think.
PS, FYI, As far as _f and _ff outputs are concerned: "....two Matlab scripts, which are useful when calculating the deterministic steady state outside Dynare++. The scripts are created by Dynare++ as soon as an input file is parsed, that is before any calculations. The first Matlab script having a name modname f.m ...calculates a residual of the static system. ...The second script having a name modname ff.m calculates a (Jacobian) matrix: df(y,y,y,0)/dy ....".
THANKS.
ALL THE BEST
MICHEL
Best regards George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "G. Perendia" artilogica@btconnect.com; "Stéphane Adjemian" stephane.adjemian@gmail.com; "Sébastien Villemot" sebastien.villemot@ens.fr; "Ferhat MIHOUBI" fmihoubi@univ-evry.fr Sent: Saturday, August 02, 2008 1:45 PM Subject: Re: AIM in Dynare +PS
Hi George
- Without inspecting the code, is the recursive MEX Sylvester
solution in Dynare 4 by Ondra the same as/or similar to / the one used in Dynare++ and, also, is it based on (and explained in) his 2005 paper "Solving SDGE..." on a solving k-order with a new recursive Sylvester solution method ?
yes to both questions.
- Is then your and Ondra's (05?) paper: "Solving SDGE Models:
Approximation About The Stochastic Steady State" used for Dynare++ based on the same solution? - I could not find the article, only REPEC abstract.
Ondra later convinced me that my approach to approximation around another point that the deterministic steady state was wrong. So we never finish writing the paper. However, he implemented an iterative method for the same thing, but, to my knowledge, he never wrote a description of the algorithm. This is something I hope to be able to go back to with him at some point.
For the time being, I think that we should limit ourselves to provide k-order approximation around the deterministic steady state in Matlab.
I'm attaching unpublished notes concerning the k-order approximation. I don't know how if it is very explicit in the text, but the order in which we compute the derivatives in part 4 is important. I believe that in this version it is in the right order.
In this paper, the first order approximation is presented with tensor notations, but it is exactly the same approach that I'm currently presenting in slides with matrix notation.
All the best,
Michel
Best regards
George
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev