Dev

dev@dynare.org

3402 discussions

AIM for Dynare copyrights
by Sébastien Villemot 02 Sep '08

02 Sep '08

Hi George, I intend to give proper license headers to all files under the AIM/ subdirectory (since Gary has said that their are in the public domain). By comparing to Gary's original files, I noticed that 3 files of the Dynare distribution are not in the ZIP file downloadable from the Fed's website: * SPEigQZ.m * SPQZ.m * SPSparse.m The first two seem to be never used in the code, while the third one is simply a call to sparse() and therefore could easily be removed. Is there any good reason to keep these files, and, if yes, who owns the copyright? Best Sébastien

2 1

Re: [DynareDev] varexo problem
by Sébastien Villemot 24 Aug '08

24 Aug '08

Salut Michel, Je comprends maintenant mieux le problème avec varexo. La classe VariableTable maintient la liste des variables dynamiques, c'est à dire soit des triplets (symbol_type, symbol_id, lead/lag) pour tous les types de variables (endo, exo, exodet) Elle attribue un numéro à ce triplet lors du parsing de la variable dans le modèle (numéro noté var_id), attribué dans l'ordre d'apparition lors du parsing. Ce numéro est utilisé en interne dans ModelTree pour faire les dérivations. Après avoir parsé et fait les dérivations, on appelle la méthode VariableTable::sort() qui va classer ces triplets par ordre lexicographique et donner les nouveaux numéros associés, qu'on appellera des sort_id (la méthode n'a en fait pas besoin de faire le tri, car la structure C++ qui stocke les triplets a déjà fait ce tri, donc il suffit juste de lire les triplets dans l'ordre dans lequel ils sont stockés). C'est le sort_id (qu'on récupère avec VariableTable::getSortID()) qui est utilisé pour déterminer la colonne du jacobien; la matrice d'incidence donne le mapping entre ce sort_id et le couple (symbol_id, lead/lag), mais *uniquement pour les endogènes*. Si je comprends bien, le code Matlab suppose qu'après les colonnes des endogènes, apparaissent les colonnes des exogènes puis des exogènes déterministes, en supposant que chaque symbole occupe exactement une colonne, et dans l'ordre de déclaration de varexo ou varexo_det Dans l'état actuel du code, le préprocesseur ne donnera pas ce qu'attend le code Matlab dans les deux situations suivantes: * si une variable exogène n'est pas déclarée, comme dans ton exemple; le code Matlab attend une colonne qu'il n'utilisera jamais (ou peut-être qu'il l'attend remplie de zéros), tandis que le préprocesseur va omettre cette colonne * si une variable exogène est utilisée avec un lead/lag, ce qui n'est pas interdit (cela va juste faire un warning); dans ce cas le préprocesseur va au contraire ajouter une colonne non désirée On peut facilement résoudre le premier problème avec la solution que tu as proposée, mais je la mettrais plutôt dans VariableTable::getSortID(). Je peux m'en occuper. Pour le cas d'une exogène avec lead/lag, la solution me semble moins évidente, car je comprends mal comment on doit rendre les dérivées dans ce cas. Amitiés Sébastien Le samedi 23 août 2008 à 19:28 +0200, Michel Juillard a écrit : > Salut Sébastien, > > dans le répertoire juillard4, il y a deux fichiers *.mod, > model_financial.mod et test1.mod. La seule différence est l'ordre des > variables dans l'instruction VAREXO. > > Dans ce modèle, il y a 125 variables dynamiques (en distinguant selon > le lag). Le Jacobien par rapport aux variables exogènes commence dans > la colonne 126. > La variable exogène gdx est en 3e position dans model_financial.mod et > en 17e position dans test1.mod. > gdx apparaît dans la 55e équation et la dérivée est placée correctement > dans g1(55,128) dans model_financial_dynamic.m > Dans test1_dynamic.m, elle apparaît de manière erronnée dans g1(55,140) > et non g1(55,142) > > Le problème apparaît lorsqu'il y a des variables exogènes déclarées, > mais qui ne sont pas utilisées dans le modèle. Dans ce cas elles ne sont > pas dans variable_table. > > Je t'écris ou t'appelle plus tard, car je crois que j'ai une solution. > > amitiés > > Michel

2 3

[Fwd: disque dur de hal]
by Michel Juillard 22 Aug '08

22 Aug '08

Thanks Stéphane for warning us. We will buy a big disk for Hal. I guess that there is no need to pay Dell prices and that we can install it ourselves. What do you think? I want also to buy a new computing workstation like Hal but with two quad-processors that we will install at Chevaleret. All the best, Michel -------- Original Message -------- Subject: disque dur de hal Date: Wed, 6 Aug 2008 09:51:09 +0200 From: Stéphane Adjemian <stephane.adjemian(a)ens.fr> Reply-To: stephane.adjemian(a)ens.fr Organization: Université du Maine & CEPREMAP To: Michel Juillard <michel.juillard(a)ens.fr> CC: Sébastien Villemot <sebastien.villemot(a)ens.fr> Salut, Un petit mail pour vous signaler que je viens de planter un gros métropolis sur hal parce qu'il n'y a plus assez d'espace mémoire pour enregistrer les fichiers mh. Le disque qui contient le /home (27G) est plein. Il est vrai que je consomme beaucoup d'espace sur le disque (là j'estimais récursivement un modèle sur les US pour comparer les prévisions avec une rêgle de Taylor et les prévisions avec une fonction de perte pour la banque centrale (politique monétaire optimale)). je pense donc qu'il faudrait prévoir d'acheter un autre disque dur à la rentrée. En attendant je vais virer mes fichiers pour que vous puissiez utiliser hal (qui est actuellement inutilisable) à+ Stéphane.

3 2

Re: [DynareDev] license
by Michel Juillard 19 Aug '08

19 Aug '08

Thanks Gary! Ben, is there some version of your code available somewhere on the web? Best Michel Gary.Anderson(a)frb.gov wrote: > michel ben, > > i should put the two of you in touch. ben has done a significant amount of > work improving the "C" version of sparseAim. > his goal, which he has nearly attained, is to provide a public domain/free > ware ansii "C" version. > i suspect that the code will be more durable and faster than any of the > matlab implementations and much easier to port than the existing "C" > versions. > > i hope this is timely and helpful. > > gary > > > >

1 0

Re: [DynareDev] [Fwd: Updated: mathomatic-14.1.4-1]
by Sébastien Villemot 17 Aug '08

17 Aug '08

Salut Michel, J'ai trouvé cette page de Wikipedia qui liste les différents logiciels de calcul symbolique: http://en.wikipedia.org/wiki/Comparison_of_computer_algebra_systems Il faudrait probablement prendre le temps de regarder tous ceux qui sont libres, pour voir ce qu'on pourrait réutiliser le plus aisément. Je me pencherai sur cette question à la rentrée. Amitiés Sébastien Le samedi 16 août 2008 à 10:01 +0200, Michel Juillard a écrit : > Salut Sébastien, > > est-ce que tu penses qu'il serait possible d'intégrer certaines > fonctions de mathomatic au pre-processor, pour simplifier les exressions? > > amitiés > > Michel > > -------- Original Message -------- > Subject: Updated: mathomatic-14.1.4-1 > Date: Sat, 16 Aug 2008 08:13:26 +0200 > From: Reini Urban <rurban(a)x-ray.at> > Reply-To: The Cygwin Mailing List <cygwin(a)cygwin.com> > To: cygwin-announce(a)cygwin.com > > > > Major algorithmical bugfixes in simplify. > > The calculate command now reports the number of solutions. > Made some big improvements and bug fixes to simplification, if only > someone had reported bugs earlier! > A major, long-standing simplify command malfunction has been fixed, but > it runs a little slower. The simplify command is now logically correct > and appears to work nicely now, please tell me if not. > > See http://mathomatic.orgserve.de/changes.txt > > Cygwin build changes: > * none > > About: > Mathomatic is a highly portable, general purpose symbolic math program > that can solve, simplify, combine, differentiate, integrate, and compare > algebraic equations. It can do standard, complex number, and polynomial > arithmetic. It is extremely easy to use and has pretty colored, easily > readable display of equations. > > See http://www.mathomatic.org/ > ======================================================================== > > To update your installation, click on the "Install Cygwin now" link on > the http://cygwin.com/ web page. This downloads setup.exe to your > system. Then, run setup and answer all of the questions. > > *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** > > If you want to unsubscribe from the cygwin-announce mailing list, look > at the "List-Unsubscribe: " tag in the email header of this message. > Send email to the address specified there. It will be in the format: > > cygwin-announce-unsubscribe-you=yourdomain.com(a)cygwin.com > > If you need more information on unsubscribing, start reading here: > > http://sources.redhat.com/lists.html#unsubscribe-simple > > Please read *all* of the information on unsubscribing that is available > starting at this URL. >

2 1

[Fwd: Re: [Fwd: Re: AIM in Dynare +PS]]
by Michel Juillard 16 Aug '08

16 Aug '08

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(a)perendia.orangehome.co.uk> To: <michel.juillard(a)ens.fr> References: <48966576.9060700(a)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(a)ens.fr> To: "List for Dynare developers" <dev(a)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(a)ens.fr> To: "G. Perendia" <artilogica(a)btconnect.com>; "Stéphane Adjemian" <stephane.adjemian(a)gmail.com>; "Sébastien Villemot" <sebastien.villemot(a)ens.fr>; "Ferhat MIHOUBI" <fmihoubi(a)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 > _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

1 0

Probability distributions
by Sébastien Villemot 12 Aug '08

12 Aug '08

Hi all, I have started the work of rewriting distribution-related functions, beginning by the easiest one (the normal). Concerning the others, a few points: 1) I discovered that prior_draw.m contains at the bottom a function which draws samples from a gamma. This would solve our copyright problem with gamm_rnd.m, if you confirm to me that you wrote it. 2) In some files, there is code for an inverse gamma of type 2 (represented by integer 6 in Dynare). This distribution is not handled by the preprocessor at this time. Should I add it ? Note that rndprior.m doesn't handle it, while prior_draw.m and draw_prior_density.m do. 3) Just for your information, note that the wikipedia page on the inverse gamma (http://en.wikipedia.org/wiki/Inverse-gamma_distribution) documents a distribution similar to your type-2-inv-gamma (up to a parameter rescaling). I could not find any page on your type-1-inv-gamma (represented by integer 4 in Dynare). This took me some time to understand, until I looked at the headers of lpdfig1.m and lpdfig2.m. Therefore it seems that the definition of what is inverse gamma is not really standardized. 4) There are some factorization opportunities which I would like to take advantage of: * in prior_draw.m: currently does not take advantage of beta_rnd.m (while rndprior.m does) * in draw_prior_density.m: we could use the new PDF functions instead of rewriting the PDF in an inline fashion * factorize code for the two inverse gammas Best Sébastien

4 11

Re: [DynareDev] license
by Michel Juillard 05 Aug '08

05 Aug '08

Thanks Gary, this is good, but we should add "author: Gary Anderson" before this text. All the best, Michel Gary.Anderson(a)frb.gov wrote: > michel, > > i had just copied some language used by someone in the same position. i > remember thinking the wording should be different too. > how about: > > > >> % Note: This program is in the public domain and may be used freely. >> % however the authors would appreaciate acknowledgement of the source by >> > citation of any > >> % of the following papers >> >> %Anderson, G and Moore, G >> %"A Linear Algebraic Procedure for Solving Linear Perfect Foresight >> Models." >> %Economics Letters, 17, 1985. >> >> % Anderson, G. >> %"Solving Linear Rational Expectations Models: A Horse Race" >> %Computational Economics, 2008 vol 31 issue 2 pages 95-113 >> >> %Anderson, G. >> %"A Reliable and Computationally Efficient Algorithm for Imposing the >> Saddle Point Property in Dynamic Models" >> %Journal of Economic Dynamics and Control, Forthcoming >> >> thanks, >> gary >> > > gary > > > > Michel Juillard > <michel.juillard@ > ens.fr> To > Gary.Anderson(a)frb.gov, Sébastien > 08/02/2008 09:04 Villemot > AM <sebastien.villemot(a)ens.fr> > cc > > Subject > Re: license > > > > > > > > > > > Hi GAry, > > Sébastien who is more attentive than me, remarked that it is > contradictory to claim a Copyright and put it in the public domain. > > We would suggest something like > > This program is in the public domain. Author: Gary Anderson > > All the best, > > Michel > > > > Gary.Anderson(a)frb.gov wrote: > >> michel, >> since i'm a US federal employee, all the code is actually freely >> > available > >> and in the public domain. >> but, if it's not to much trouble, it would be nice to have an >> > attribution > >> along the following lines: >> >> % (c) Gary S Anderson 2005 >> % >> % Note: This program (and associated subroutines) may be used freely >> % subject to acknowledgement of the source and citation of any >> % of the following papers >> >> %Anderson, G and Moore, G >> %"A Linear Algebraic Procedure for Solving Linear Perfect Foresight >> Models." >> %Economics Letters, 17, 1985. >> >> % Anderson, G. >> %"Solving Linear Rational Expectations Models: A Horse Race" >> %Computational Economics, 2008 vol 31 issue 2 pages 95-113 >> >> %Anderson, G. >> %"A Reliable and Computationally Efficient Algorithm for Imposing the >> Saddle Point Property in Dynamic Models" >> %Journal of Economic Dynamics and Control, Forthcoming >> >> thanks, >> gary >> >> >> >> > > >> Michel Juillard >> > > >> <michel.juillard@ >> > > >> ens.fr> >> > To > >> Gary.Anderson(a)frb.gov, Sébastien >> > > >> 07/30/2008 11:31 Villemot >> > > >> AM <sebastien.villemot(a)ens.fr>, >> > > >> Stéphane Adjemian >> > > >> <stephane.adjemian(a)gmail.com>, >> > > >> George Perendia >> > > >> <artilogica(a)btconnect.com> >> > > > cc > > > > Subject > >> license >> > > > > > > > > > > > > > > >> >> >> Dear Gary, >> >> George has finished the implementation of Aim in Dynare. It is available >> under SVN. >> As we are in the process to c leaning Dynare code, we want to add proper >> Copyrights and license agreement. >> As we are distributing Dynare under the GPL v3, we would like to add to >> your files >> Copyright Gary Andersen (2005) and distribute them as well under GPLv3. >> If your prefer you can choose to have them distributed under a less >> restrictive license such as BSD. >> >> All the best, >> >> Michel >> >> >> >> >> >> > > > > >

1 0

Kirikou
by Sébastien Villemot 04 Aug '08

04 Aug '08

Hi all, I set up a wiki page to describe the main points of the configuration of Kirikou: http://www.cepremap.cnrs.fr/DynareWiki/KirikouConfiguration We should expand this page as we migrate stuff from pythie to kirikou. Michel: I set up a wiki on http://www.monfispol.eu/MonFisPolWiki (I chose to use a more explicit name than InternalWiki, because it could become confusing when we migrate all our wikis to kirikou) For the moment everybody can write on this wiki without any restriction; please fix /etc/moin/monfispolwiki.py when you have decided who can write on this wiki Stéphane: * I moved the Ubuntu repository to /srv/d_kirikou/www.dynare.org (see the top of the wiki page for the reason why) * maybe you could write a few lines about the configuration of your private SVN Best Sébastien

3 4

[Fwd: Re: AIM in Dynare +PS]
by Michel Juillard 04 Aug '08

04 Aug '08

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(a)ens.fr> To: "G. Perendia" <artilogica(a)btconnect.com>; "Stéphane Adjemian" <stephane.adjemian(a)gmail.com>; "Sébastien Villemot" <sebastien.villemot(a)ens.fr>; "Ferhat MIHOUBI" <fmihoubi(a)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 >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev