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

...

1. 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.

...

2. 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