- Dev - dynare.org

An update on parallelization on GPU
by Sébastien Villemot 15 Jul '11

15 Jul '11

Hi, This morning I have documented myself a little bit on the subject of exploiting parallelization on GPUs (Graphical Processing Units). George had made a presentation on this topic a few years ago, and things have evolved a little bit since. There seem to be now two major competing programming frameworks for parallelization on GPUs (and possibly CPUs also): - CUDA, developed by Nvidia [1] - OpenCL, presented by a consortium (including Apple, AMD, ATI, Nvidia) [2] CUDA was initially only available on Nvidia graphics cards (see the packages "nvidia-cuda-*" in Debian, which contain the non-free implementation of CUDA for Nvidia cards). There is now a free implementation of CUDA, called GPU Ocelot [3], which looks promising. It is able to run CUDA programs on an heterogenous cluster of GPUs (Nvidia, AMD, Intel) and CPUs (multi-core x86). It is not yet packaged in Debian, but it seems very interesting and we should give it a try. On the long term, OpenCL looks more promising, but there is currently no free implementation of it. There is a Debian package called "opencl-headers", but it contains only the headers, since the binary implementation is non-free. There are also Debian packages containing the Nvidia non-free implementation of OpenCL (see "nvidia-opencl-*"). I am not aware of any ongoing project to build a free implementation of OpenCL. To summarize: whoever has the interest and time in our team should give a try to GPU Ocelot to see if we can take advantage of it in Dynare. Don't hesitate to react to this mail if you know things on this topic of which I am not aware. Best, [1] http://en.wikipedia.org/wiki/CUDA [2] http://en.wikipedia.org/wiki/OpenCL [3] http://code.google.com/p/gpuocelot/ -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 2069 1DFC C2C9 8C47 9529 84EE 0001 8C22 381A 7594

2 1

Fwd: Re: Suggestion
by Michel Juillard 14 Jul '11

14 Jul '11

... Thanks Johannes. This is an excellent suggestion. I pushed the modification to GIT. All the best Michel On 07/14/2011 12:01 PM, Johannes Pfeifer wrote: > /Please check i) if all parameters occurring in these equations are > defined and ii) that no division by an endogenous variable initialized > to 0 occurs. /

1 0

[Trac] #189: identification options
by Trac Dynare 12 Jul '11

12 Jul '11

#189: identification options --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- Add lik_init and/or diffuse_filter -- Ticket URL: <https://www.dynare.org/trac/ticket/189> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #187: macrovariable passed on the command line (-D option)
by Trac Dynare 12 Jul '11

12 Jul '11

#187: macrovariable passed on the command line (-D option) --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- It works for numerical values but not for strings. In the test.mod file: @#if var1 == "a" @#echo "OK" @#else @#echo "NO" @#endif Calling dynare test -Dvar1=a will fail with with unknown variable a (without any Dynare instruction, it is normal that test.mod fails at the end, but with an error message about unexpected $end) -- Ticket URL: <https://www.dynare.org/trac/ticket/187> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #193: add new sensitivity options
by Trac Dynare 12 Jul '11

12 Jul '11

#193: add new sensitivity options --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- pvalue_ks (default 0.001) threshold pvalue for significant Kolmogorov Smirnov test (i.e. plot parameters with pvalue<pvalue_ks) pvalue_corr (default 0.001) threshold pvalue for significant correlation in filtered samples (i.e. plot bivariate samples when pvalue<pvalue_corr) -- Ticket URL: <https://www.dynare.org/trac/ticket/193> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #192: Bug in irf_shocks (reported by Johannes Pfeifer)
by Trac Dynare 12 Jul '11

12 Jul '11

#192: Bug in irf_shocks (reported by Johannes Pfeifer) --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- * when specifying options_.irf_shocks in stoch_simul, Dynare crashes * also add irf_shocks to estimation command -- Ticket URL: <https://www.dynare.org/trac/ticket/192> Dynare <http://www.dynare.org> The Dynare project

1 2

timings
by Stéphane Adjemian 25 Jun '11

25 Jun '11

Salut Ferhat, J'étais un peu étonné par les gains de temps (pour l'estimation de sw) que tu annonces dans tes slides. Voilà les résultats que j'obtiens sur mon portable : block+bytecode ........ 256 sec. (comme toi) linear ................ 215 sec. linear+use_dll ........ 209 sec. no options ............ 280 sec. (largement < 9 minutes annoncées). Clairement c'est mieux d'utiliser block+bytecode que rien du tout, mais la différence est marginale. La meilleure solution c'est quand même linear+use_dll (en fait c'est linear qui fait la différence). Bref je crois qu'il y a un problème avec tes comparaisons. Je vais essayer sur un SW non linéaire... à+ Stéphane.

2 1

[Trac] #185: parallel computing: default missing for option NodeWeight
by Trac Dynare 14 Jun '11

14 Jun '11

#185: parallel computing: default missing for option NodeWeight --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- ./matlab/parallel/InitializeComputationalEnvironment.m crashes when no value is indicated for node weights in Dynare configuration file -- Ticket URL: <https://www.dynare.org/trac/ticket/185> Dynare <http://www.dynare.org> The Dynare project

3 5

[Trac] #186: normalization is buggy in preprocessor for expressions of the form a^x
by Trac Dynare 10 Jun '11

10 Jun '11

#186: normalization is buggy in preprocessor for expressions of the form a^x --------------------------+------------------------------------------------- Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.2.1 Keywords: | --------------------------+------------------------------------------------- In ExprNode.cc, in the function BinaryOpNode::normalizeEquation, the case of an expression of the form a^x (power expression with endogenous in the exponent but not under the exponent) is not handled. This make the preprocessor exit silently with an error. -- Ticket URL: <https://www.dynare.org/trac/ticket/186> Dynare <http://www.dynare.org> The Dynare project

1 2

Release of Dynare 4.2.1
by Sébastien Villemot 24 May '11

24 May '11

Dear Dynare users, We are pleased to announce the release of Dynare 4.2.1. Many bugs have been fixed since the previous release. The reference manual has also been improved: new contents has been added at various places, the structure has been improved, an index of functions and variables has been added, the PDF/HTML rendering has been improved. The Windows package is already available for download at the official Dynare website [1]. The Mac and Linux packages should follow soon. All users are strongly encouraged to upgrade. This release is compatible with MATLAB versions ranging from 7.0 (R14) to 7.12 (R2011a) and with GNU Octave versions ranging from 3.0 to 3.4. Here is a list of the main bugfixes since version 4.2.0: * The `STEADY_STATE' operator has been fixed * Problems with MATLAB 7.3 (R2006b) and older have been fixed * The `partial_information' option of `stoch_simul' has been fixed * Option `conditional_variance_decomposition' of `stoch_simul' and `estimation' has been fixed * Automatic detrending now works in conjunction with the `EXPECTATION' operator * Percentage signs inside strings in MATLAB statements (like disp('% This is not a comment %')) now work * Beta prior with a very small standard deviation now work even if you do not have the MATLAB Statistical toolbox * External functions can now been used in assignment of model local variables * `identification' command has been fixed * Option `cova_compute' of `estimation' command has been fixed * Random crashes with 3rd order approximation without `use_dll' option have been eliminated [1] http://www.dynare.org On behalf of the Dynare team, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

Categories of software
by Sébastien Villemot 13 May '11

13 May '11

Just for information, a good web page which explains the different categories of software (free, open-source, proprietary, public domain…) and of licenses: http://www.gnu.org/philosophy/categories.html -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #170: document macro-processor in the reference manual
by Trac Dynare 06 May '11

06 May '11

#170: document macro-processor in the reference manual ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: minor | Milestone: 4.3 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ And also, mention the fact that it is not possible to create a macro-loop around the model block. -- Ticket URL: <https://www.dynare.org/trac/ticket/170> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #180: Adapt the testsuite for MATLAB
by Trac Dynare 06 May '11

06 May '11

#180: Adapt the testsuite for MATLAB --------------------------------------+------------------------------------- Reporter: sebastien | Owner: houtanb Type: feature | Status: new Priority: major | Milestone: Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- In particular this will help verifying that all functionalities work with old MATLAB versions. -- Ticket URL: <https://www.dynare.org/trac/ticket/180> Dynare <http://www.dynare.org> The Dynare project

1 1

Planning release of 4.2.1
by Sébastien Villemot 02 May '11

02 May '11

Hi, I think we should now prepare for the release of 4.2.1: we released 4.2.0 almost 3 months ago, and we found many bugs. Before the release can happen, we need to fix several tickets. I list them below, along with the person responsible for fixing it. If you feel you need some help for fixing it within one week or two, let me know. - Problem with computation of planner objective (Michel) https://www.dynare.org/trac/ticket/166 - Crash in partial information (George) https://www.dynare.org/trac/ticket/179 - Possible bug in DSGE-VAR (Stéphane) https://www.dynare.org/trac/ticket/177 There are also two issues with the reference manual: - Entry for unit_root_vars https://www.dynare.org/trac/ticket/167 - Forecast graphs https://www.dynare.org/trac/ticket/102 -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 3

[Trac] #178: merge GSA documentation into the reference manual
by Trac Dynare 02 May '11

02 May '11

#178: merge GSA documentation into the reference manual ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.3 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ The document is here: http://www.dynare.org/documentation-and-support/global-sensitivity- analysis http://eemc.jrc.ec.europa.eu/EEMCArchive/Software/DynareCourse/GSA_manual.p… -- Ticket URL: <https://www.dynare.org/trac/ticket/178> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #179: Crash in partial information
by Trac Dynare 02 May '11

02 May '11

#179: Crash in partial information --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.2.0 Keywords: | --------------------------+------------------------------------------------- The attached MOD file makes Dynare crash in the partial information code. -- Ticket URL: <https://www.dynare.org/trac/ticket/179> Dynare <http://www.dynare.org> The Dynare project

2 2

[Trac] #182: Document DSGE-VAR in the ref manual
by Trac Dynare 29 Apr '11

29 Apr '11

#182: Document DSGE-VAR in the ref manual ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ -- Ticket URL: <https://www.dynare.org/trac/ticket/182> Dynare <http://www.dynare.org> The Dynare project

1 0

calling Matlab functions with no arguments
by Michel Juillard 27 Apr '11

27 Apr '11

In recent versions of Matlab, calling functions with no input arguments can be indicated with empty parentheses (). However this syntax is not allowed in older versions of Matlab. I searched, but couldn't find which version starts to authorize the () construct. Some time ago, we had decided not to use () in Dynare, but those have reappeared for some time. As far as I can see, the problem has not be mentioned on the forum since the end of 2008, but I have just received a message from somebody in Madagascar who encountered it. We should either remove () or find the Matlab version that first authorizes it and modify the mention that Dynare works with Matlab version 6.5 and above Please, tell me what you think Best Michel

3 8

[Trac] #165: Fix problems with Octave 3.4
by Trac Dynare 21 Apr '11

21 Apr '11

#165: Fix problems with Octave 3.4 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: 4.2.0 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/165> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] identification preprocessor
by Sébastien Villemot 20 Apr '11

20 Apr '11

Marco Ratto <marco.ratto(a)jrc.ec.europa.eu> writes: > Concerning documentation, I am now trying to rush with the coding, then I will > write a detailed manual for the identification toolbox. > Concerning texinfo, it looks nice but no experience: where are texinfo files in > dynare repository so I can learn a bit from them? Is there an easy way to > compile' texinfo sources to preview my editing? The ideal way of documenting stuff in Dynare is now the following: - the list of commands and options with their description should go in the reference manual; - the details of the methodology and of the algorithms should go in a working paper in our new Dynare working papers series. Of course each of the document can refer to the other, but we should try to stick as much as possible to this separation. Concerning Texinfo, I have written a wiki page: http://www.dynare.org/DynareWiki/ReferenceManual Under Windows, it is easy to compile the manual using the "texinfo" package of Cygwin. Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 1

7th Dynare Conference (Call for Papers)
by Sébastien Villemot 20 Apr '11

20 Apr '11

Dear all, The 7th annual DYNARE Conference (www.dynare.org) will be held in Atlanta on September 9-10, 2011. The conference is organized by the Center for Quantitative Economic Research (CQER) at the Federal Reserve Bank of Atlanta together with DSGE-net and the Dynare project at CEPREMAP. The DYNARE conference will feature the work of the leading scholars in dynamic macroeconomic modeling and provide an excellent opportunity to present your own research results. Lars Peter Hansen (University of Chicago) and Giorgio Primiceri (Northwestern University) will be plenary speakers. Submission of the papers focusing on the following issues is encouraged: - Model uncertainty and optimal policy; - Imperfect information and learning; - Model and parameter identification; - Occasionally binding financial constraints. The list is not all-inclusive. Submissions of papers dealing with different aspects of DSGE modelling and computational methods are all welcome. Submissions of papers using other software tools than DYNARE or theoretical contributions are also encouraged. Complete manuscripts or detailed abstracts should be sent in PDF format to Hanane Bahala at the following address: hanane.bahala(a)ens.fr Deadline for submissions is May 15, 2010. Authors of accepted papers will be informed by June 1, 2011. Organizers: - Michel Juillard (Bank of France); - Daniel Waggoner (Federal Reserve Bank of Atlanta); - Tao Zha (Federal Reserve Bank of Atlanta and Emory University). We apologize for multiple posting. -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

Dynare Working Papers series
by Stéphane Adjemian 15 Apr '11

15 Apr '11

Dear all, The Dynare team is pleased to announce the creation of the Dynare Working Papers series [1]. The Dynare Working Papers series is intended for the following kind of contributions: * methodological papers related to current or forthcoming Dynare functionality; * papers in quantitative macroeconomics whose results (or portion thereof) have been obtained with the help of Dynare. Authors are encouraged to submit papers falling into one of the two aforementioned categories, even if they have already been published in another working papers series. Note that contributions not directly related to Dynare, but still pertaining to the fields of numerical methods or of quantitative macroeconomics, are also welcome. Submissions should be sent by e-mail to: wp(a)dynare.org. We commit ourselves to giving a fast and fair editorial decision, but please forgive us if you do not receive a full-fledged referee report in return. The goal of this series being state of the art dissemination, the source code of computer programs used in the paper should also be included in the submission (this covers Dynare MOD files and/or any other program, whether written in MATLAB, Octave, Fortran, C, C++, etc). If the submission is accepted, the source code will be made publicly available on our website. Papers and codes published in the series are automatically added to the RePEc [2] database. We are waiting for your contributions! Stéphane and Sébastien. [1] http://www.dynare.org/wp [2] http://ideas.repec.org/s/cpm/dynare.html

2 1

[Trac] #176: preprocessor fails when external functions are assigned to model local variables
by Trac Dynare 12 Apr '11

12 Apr '11

#176: preprocessor fails when external functions are assigned to model local variables --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: 4.2.0 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/176> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #114: IRF: add an option to limit the exogenous shocked in the computations
by Trac Dynare 01 Apr '11

01 Apr '11

#114: IRF: add an option to limit the exogenous shocked in the computations --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/114> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #171: implement the possibility of passing macro-processor defines on the command-line
by Trac Dynare 30 Mar '11

30 Mar '11

#171: implement the possibility of passing macro-processor defines on the command-line --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: minor | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- ...like gcc does with the -D option. -- Ticket URL: <https://www.dynare.org/trac/ticket/171> Dynare <http://www.dynare.org> The Dynare project

1 3

Reference manual in Texinfo
by Sébastien Villemot 29 Mar '11

29 Mar '11

Hi all, I have converted the Dynare reference manual to the Texinfo format, which is easier to edit than Docbook. We hope this will make easier contributions to the reference manual. You need to run "autoreconf" in your git repository in order to be able to compile things again. Documentation on this new format is on a wiki page: http://www.dynare.org/DynareWiki/ReferenceManual Note that in translating to Texinfo, I also made the following improvements: * there are now 2 indices at the end of the file: one for functions and commands, the other for variables (in particular fields of "oo_") * I updated the introduction, using the frontpage of the website * I split the old "Solving and simulating" section into four subsections: steady state, model checks, deterministic simulations, stochastic simulations * the HTML output looks better for math formulas (see the wiki page for details) Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 1

Re: [DynareDev] [Trac] #5: Implement explicit writing of first order conditions of Ramsey problem
by Trac Dynare 28 Mar '11

28 Mar '11

#5: Implement explicit writing of first order conditions of Ramsey problem ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: enhancement | Status: closed Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * status: accepted => closed * resolution: => fixed Comment: in commit 161647922cf8c920843e6f32d8bc3c5a2aed2b35 -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:6> Dynare <http://www.dynare.org> The Dynare project

1 0

Fwd: Identification of Bayesian DSGE models
by Michel Juillard 25 Mar '11

25 Mar '11

May be of interest to you. Best Michel -------- Original Message -------- Subject: Identification of Bayesian DSGE models Date: Wed, 23 Mar 2011 18:01:33 +0000 From: Ron Smith <r.smith(a)econ.bbk.ac.uk> To: <michel.juillard(a)ens.fr> Dear Prof Juillard You may be interested in the attached paper with Hashem Pesaran and Gary Koop. It considers how prior and posterior differ for unidentified parameters and suggests a fairly easy way to check local identification by simulating the model on different sized samples. Best wishes Ron Smith Prof Ron P Smith, Economics, Birkbeck College, Malet Street, London WC1E 7HX Tel 44 (0)20 7631 6413 Fax 6416 Home page: http://www.ems.bbk.ac.uk/faculty/smith/index_html

2 1

optimizer n. 5
by Marco Ratto 18 Mar '11

18 Mar '11

Dear Michel and Sebastien, a couple of weeks ago I committed a change to the optimizer n.5 which we decided not to cherry pick to 4.2 since it was not a debug and but an improvement. In fact, I think we could port it to 4.2 because I realized that in some cases it fixes a bug. The problem arises when we have relatively short data series (say 60 quarters), but a quite large number of observed series (say 20-25). Assume we have 70 parameters to estimate, the outer product gradient used by mode_compute=5 in version 4.2 is rank deficient as if there was insufficient data to estimate 70 params while the data (e.g. 60x20) are more than enough. The modifications I did would fix this for 4.2. What do you think? please let me know how to proceed thanks for your help best Marco -- Marco Ratto, (http://easu.jrc.ec.europa.eu/), Joint Research Centre The European Commission, TP 361, 21027 ISPRA(VA), ITALY Tel: +39 0332 78 5639 Fax: +39 0332 78 5733 marco.ratto(a)jrc.ec.europa.eu

2 1

GSA in Dynare [was Re: svn repository]
by Sébastien Villemot 17 Mar '11

17 Mar '11

I have merged Global Sensitivity Analysis toolbox (GSA) into the main Dynare repository, keeping the history of the project. The files are now organized as follows: - matlab/gsa: main GSA files - doc/gsa: documentation - tests/gsa: example MOD files Concerning the documentation, I incorporated it into the build system: it should be recompiled with "make pdf" provided you have a TeX installation. Concerning the MATLAB files: - they are now automatically included in MATLAB path; - we will solve the indentation problems at the next global reindentation, just before the release of Dynare 4.3; - I began tackling copyright problems, by removing functions which had a bad copyright and were redundant with free functions provididing the same functionality (beta/gamma/gaussian CDF/quantile functions); Marco: please check commit cde4f038d74166ba016d3e10f961dc36c69afd1f for any mistake; - there are still copyright problems which need to be solved; I opened a ticket on that (https://www.dynare.org/trac/ticket/173). Marco: please have a look at the problematic functions and see if we can find a solution (replacing them by a free one, or getting the permission from the original author to distribute its file under GPL or public domain). Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 4

[Trac] #168: steady_state operator + oo_.steady_state versus dr.ys
by Trac Dynare 14 Mar '11

14 Mar '11

#168: steady_state operator + oo_.steady_state versus dr.ys --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: enhancement | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The steady_state operator is currently implemented via the global variable oo_.steady_state in *_dynamic.m It would be preferable to pass it as argument It is also necessary to clarify the respective role of oo_.steady_state and dr.ys In perfect foresight models where the terminal steady state is different from the initial one, we need to clarify which steady state the steady_state operator refers to. Whatever change is made, must be done for *_dynamic.m *_dynamic.mex* and in bytecode -- Ticket URL: <https://www.dynare.org/trac/ticket/168> Dynare <http://www.dynare.org> The Dynare project

1 3

steady state operator
by Michel Juillard 14 Mar '11

14 Mar '11

The temporary fix used to solve the bug for the steady_state operator (updating oo_.steady_state in resol.m) created a problem for estimation when the steady state is recomputed numerically at each iteration. Before the change, numerical computation of the steady state was always using the same intial value (oo_.steady_state) for the nonlinear solution algorithm. After the change, the initial value was the steady state at the last evaluation. It appears that it deteriorates in an important manner the performance of the optimizer, that stops before reaching the mode. at least in some examples that where working fine before the change. I have now made the steady state vector an additional argument to the *_dynamic() function and changed all the calls accordingly. The changes have been uploaded to GIT. There is a remaining problem for bytecode that is currently broken, but Ferhat is looking into it. Then, I reverted the change to resol.m and, in estimation, the nonlinear function for finding the steady state again starts always from the same initial point. Best Michel

3 4

[Trac] #169: recent change to oo_.steady_state breaks estimation
by Trac Dynare 14 Mar '11

14 Mar '11

#169: recent change to oo_.steady_state breaks estimation --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The commit 9f7cfaec007f0d4aa805047823c3fb4ce020d6b9 has broken estimation, in particular of fs2000.mod. The mode optimization fails: {{{ POSTERIOR KERNEL OPTIMIZATION PROBLEM! (minus) the hessian matrix at the "mode" is not positive definite! => posterior variance of the estimated parameters are not positive. You should try to change the initial values of the parameters using the estimated_params_init block, or use another optimization routine. warning: The results below are most likely wrong! }}} Commenting out line 123 of resol.m fixes the problem: {{{ oo_.steady_state = steady_state; }}} -- Ticket URL: <https://www.dynare.org/trac/ticket/169> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] bug in resol
by Michel Juillard 09 Mar '11

09 Mar '11

Thanks Marco for finding this tricky bug. It is a complicated issue that stems from two poor design decisions: 1) using the global variable oo_.steady_state in *_dynamic.m 2) an unclear distinction between oo_.steady_state and dr.ys: the rule that I had in mind was - oo_.steady_state is set by instructions initval and steady - dr.ys is the steady state computed for local approximation But this is not good enough and as you found out creates problem for steady_state operator What makes the problem complicated is that the solution must work both for the simulation of deterministic models where dr.ys is not computed and for the (repeated, in estimation) local approximation of stochastic model where oo_.steady_state is currently not updated for new values of the parameters. A temporary fix is to set oo_.steady_state in resol.m. I will make that change and update to GIT today. In the long run, we have to find a way to pass the steady state values to *_dynamic.m as an argument and not as a global Best Michel On 3/8/2011 9:54 PM, Marco Ratto wrote: > Dear Friends, > > playing quite intensively with a model including the STEADY_STATE > syntax in model definition, I stepped into a subtle bug: > > when dynare_resolve is called, the resol routine checks if ys is the > steady state, if not it re/computes it and updates dr.ys and oo_.dr.ys. > However, oo_.steady_state is not updated and the latter is used in > <model>_dynamic.m. This implies a wrong model solution. > In order to fix it I would simply update oo_.steady_state before > calling dr1 or dr_block in resol.m. > Otherwise, if there is a reason why only dr.ys should be kept updated > laving oo_.steady_state as it is now, then the pre-processor has to be > changed and the use of oo_.steady_state in _dynamic and param_derivs > files should be replaced by oo_.dr.ys. > > Just let me know how I should proceed. > Many thanks for your help > best > Marco >

3 2

Dynare Website
by stephane.adjemian＠gmail.com 26 Feb '11

26 Feb '11

Dear all, We have just changed the first page on the Dynare website. Please have a look, all feedbacks are welcome. Best, Stéphane. -- Stéphane Adjemian Université du Maine, GAINS & CEPREMAP http://www.dynare.org/stepan

4 3

Re: [DynareDev] identification/sensitivity
by Michel Juillard 22 Feb '11

22 Feb '11

I think that it is my mistake: I wrote dynare_estimation_init.m for sensitivity/identification but never end up using it in dynare_estimation_1.m My preferred solution would be -to make a new version of dynare_estimation_init.m by using lines 1-303 of dynare_estimation_1.m -add an argument for gsa as in the current version of dynare_estimation_init.m -removes lines 1-303 from dynare_estimation_1.m and call dynare_estimation_init Best Michel On 02/18/2011 04:00 PM, Marco Ratto wrote: > Dear Michel, Sebastien, > I just realized that, a part from identification, also sensitivity > analysis is broken under 4.2. It is my fault not having checked this > before [at least they are not official features ...]. > I hope to have time to work on it and fix all problems next week. > > One point concerns dynare_estimation_init.m: > > At some point in the past Michel did it, breaking dynare_estimation, > in order to provide initialization of the estimation environment, then > dynare_estimation would do actual estimation while sensitivity or > identification would do other things. > Now the 4.2 developments are such that dynare_estimation_init is > isolated from dynare, except that it is called from > identification/sensitivity and I have to replicate there all the > initialization commands which are now done in dynare_estimation + > dynare_estimation_1. > > Essentially dynare_estimation_init is a dumplicate of a large portion > of the dynare estimation routines. > > My question is if I can study a way where dynare_estimation_init is > simply eliminated and I directly use the common dynare estimaton > routines to initialize the environment with some return commands that > exit routines prior to estimation when we call them from > identification or sensitivity. > > Do you think this is something reasonable? > > please let me know > all the best > Marco >

4 7

Dynare Quickstart
by Sébastien Villemot 21 Feb '11

21 Feb '11

Hi all, Vincent Crevot has written a "quick start" page for Dynare: http://www.dynare.org/documentation-and-support/quick-start It is targetted for Windows users (which represent the vast majority of our users). Please let us know if you have any comments or suggestions of improvements. Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 1

Re: [DynareDev] prior specification on SBVAR coefficients
by Michel Juillard 19 Feb '11

19 Feb '11

Hi Jake, I know that you all are busy with the new release, but I wanted to try and keep things moving on the ms-sbvar code. Excellent! > I wanted to make a suggestion on the pre_processor inputs to handle > some of the new functionality that we wanted to be have in ms_sbvar. > > 1.) Instead of having "estimate_model" could this be changed to > "mode_file=FILENAME" similar to the estimation command for dsge models? > It needs to be coupled with mode_compute=0, even if there are not alternative algorithms for computing mode for MS SBVAR models > 2.) To have a user be able to load previous simulations could they > specify "load_mh_file" Yes > > 3.) For the Impulse Response Functions, should the user specify > "irf=INTEGER" or "bayesian_irf" > irf=INTEGER specifies the length of the IRF (in solving/simulation and in estimation) bayesian_irf requests the posterior distribution of the IRFs (in estimation) so in estimation context, both options may be used > 4.) Should "optim=()" be added for the user to be able to adjust > csminwel options (maximum block iterations, convergence increment > value, etc.) > optim=() was designed a long time ago to pass optimization options for Matlab's fmincon(). It has the advantage of passing option names that are not known from the preprocessor. It would certainly be desirable to let the user specify options for csminwel. I'm a bit hesitant about just passing arbitrary option names as in in optim=() or putting in the preprocessor the list of options for each optimizer known to Dynare that can be changed by the user. What do you think? > 5.) The simulation options can be simplified to work with Dan's new code: > > n_draws=INTEGER (draws to save) Should this be changed to mh_replic= ? yes > burnin=INTEGER we use drop=INTEGER > thinning_factor=INTEGER what exactly does thinning_factor? > mh=INTEGER (Tuning period for adaptive MH), perhaps another name > 'adaptive_mh_draws'? adaptive_mh_draws is OK by me We should probably also use adaptive_mh_draws in DSGE estimation > (thin*n_draws+burnin = total number of draws) > > The current options in the preprocessor that relate to simulation options: > > n_draws > thinning_factor > proposal_draws > draws_nbr_burn_in_1 > draws_nbr_burn_in_2 > draws_nbr_mean_var_estimate > draws_nbr_modified_harmonic_mean > dirichlet_scale > > All the best, Michel > Jacob Smith > Quantitative Research Analysis Specialist > Federal Reserve Bank of Atlanta > 1000 Peachtree St NE > Atlanta, GA 30309-4470 > Phone: 404.498.8093 > Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> > > On Feb 16, 2011, at 5:20 AM, Sébastien Villemot wrote: > >> Hi Jake, >> >> I didn’t merge your changes. To achieve your goal, you don’t need to >> introduce a new "vec_float" rule and all the associated logic (by the >> way, >> we should not use floats but doubles). >> >> A very easy way to achieve the same goal is to use "vec_value" in the >> Bison file. It is already used by "o_gsa_threshold_redform" option, and >> I think it does what you need. The strings are never converted to >> doubles, but we don’t need to have them converted: we just pass them >> over to MATLAB. >> >> Please update your changes (which should now become very minimal). >> Sorry for the inconvenience. >> >> Best, >> >> Jacob Smith <jacob.smith(a)atl.frb.org >> <mailto:jacob.smith@atl.frb.org>> writes: >> >>> Hi Michel, >>> >>> These changes have been pushed. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 13, 2011, at 12:41 PM, Michel Juillard wrote: >>> >>> Hi Jake, >>> >>> thanks. I understand now. I looked at your last changes pushed to >>> dynare-jake.git >>> 1) your changes to ParsingDriver.cc (+hh) remove void >>> ParsingDriver::add_steady_state_model_equal_multiple() at the very >>> end of the file. I don't understand the change >>> 2) There is also a change to spaces in add_expectation() >>> 3) I prefer the longer option name >>> "coefficients_prior_hyperparameters" to the more cryptic "sz_prior" >>> >>> Could you please modify your last change and push it again? >>> >>> All the best >>> >>> Michel >>> >>> On 02/11/2011 10:11 PM, Jacob Smith wrote: >>> >>> Hi Michel, >>> >>> My apologies for the confusion in my last email, my addition >>> was to the ms_sbvar options list, so that the user just adds an >>> option if they want to change the hyper >>> parameters that relate to the Sims/Zha prior. I have pushed >>> these changes to the repository. >>> >>> To use Stephane's example on how you would modify the >>> hyper-parameters of the ms_sbvar model you would do the following: >>> >>> ms_sbvar(datafile = data_59Q2_05Q4, >>> freq=4, >>> initial_year=1959, >>> final_year=2005, >>> initial_subperiod=2, >>> final_subperiod=4, >>> nlags=4, >>> draws_nbr_modified_harmonic_mean=100, >>> sz_prior=[1.2,2.1,1.2,2.1,1.2,2.1] >>> ); >>> >>> The default has been set to sz_prior = [1.0 1.0 0.1 1.2 1.0 >>> 1.0], in the global_initialization.m file. >>> >>> Currently there are some bugs in the repository though that >>> have been introduced by the directories being renamed. I have not >>> wanted to step on anyone's changes so I >>> haven't made a commit to fix the problems with the >>> subdirectories (identification,etc.) in ms-sbvar not being loaded >>> into the user's path. >>> >>> I will be happy to make any modifications that you need if >>> this is not what you would prefer as it relates to how you specify >>> these hyper-parameters. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 11, 2011, at 3:15 PM, Michel Juillard wrote: >>> >>> Hi Jake, >>> >>> currently, in Dynare, the main entry point is >>> >>> swz_sbvar(ms_flag, M, options) >>> >>> whith >>> >>> ms_flag = 1: Markov Switching; =2: simple SBVAR >>> M: parameters from the *.mod file (probably the only one >>> that one needs is M.fname) >>> options: all options >>> >>> 1) we should rename swz_sbvar() to ms_sbvar() and make >>> other changes required by the renaming of the directory >>> 2) your example seems to have only a small list of >>> options, how do you pass the other ones that are listed on the wiki? >>> >>> All the best, >>> >>> Michel >>> >>> On 02/11/2011 04:01 PM, Jacob Smith wrote: >>> >>> Hi Stephane, >>> >>> I have added this capability to the version I was >>> working on with other changes for the new code from Dan. Currently I >>> had named the option 'sz_prior' but could >>> easily change it to the name you suggest Michel. It >>> allows the user to to specify a vector of 6 floats, like so: >>> >>> ms_sbvar(datafile = data, >>> freq=4,initial_year=1959, >>> final_year=2005, >>> nlags=5, >>> draws_nbr_modified_harmonic_mean=10000, >>> sz_prior=[1.2,1.1,1.2,1.1,1.2,1.1]); >>> >>> I will be happy to push the changes to the >>> preprocessor along with the changes to some Matlab files to use >>> these options to the Dynare repository. >>> >>> Jacob Smith >>> Quantitative Research Analysis Specialist >>> Federal Reserve Bank of Atlanta >>> 1000 Peachtree St NE >>> Atlanta, GA 30309-4470 >>> Phone: 404.498.8093 >>> Email: Jacob.Smith(a)atl.frb.org >>> <mailto:Jacob.Smith@atl.frb.org> >>> >>> On Feb 11, 2011, at 7:32 AM, Michel Juillard wrote: >>> >>> Hi Stephane, >>> >>> thanks for reporting the problem. I think that we >>> should do both as we have only suggested priors for monthly and >>> quarterly. The code should fail and ask the >>> user to set his/her own values for the mu's when >>> the frequency is not monthly or quarterly. >>> I suggest to call the option >>> "coefficients_prior_hyperparameters" and require the user to supply >>> a vector of 6 real numbers. >>> >>> Please, always include houtan.bastani(a)ens.fr >>> <mailto:houtan.bastani@ens.fr> in the messages relative to this project. >>> >>> Best >>> >>> Michel >>> >>> On 2/11/2011 1:20 PM, T. Zha wrote: >>> >>> Jake: >>> >>> Please investigate the following problem. >>> >>> Thank you. >>> >>> Tao >>> >>> --------- >>> On Feb 11, 2011, at 5:35 AM, >>> <Stephane.LHUISSIER(a)banque-france.fr >>> <mailto:Stephane.LHUISSIER@banque-france.fr>> >>> <Stephane.LHUISSIER(a)banque-france.fr >>> <mailto:Stephane.LHUISSIER@banque-france.fr>> wrote: >>> >>> Dear Michel and Tao, >>> >>> The dynare interface does not let the user to >>> change the prior specification on SBVAR coefficients. In the file >>> “msstart_setup” (from line 112), you can see >>> that the priors (mu) are defined for monthly >>> data. If the user wants to use quarterly data, he has to change the >>> values of mu_i directly on this file. >>> In order to improve this, I think that two >>> solutions are possible : >>> 1) Adding an interface in dynare for >>> defining its own values. >>> 2) Following Sims and Zha (1998) ‘s >>> suggestions and in this case, here is an example : >>> >>> % === The following mu is effective only if >>> options_.ms.bayesian_prior==1. >>> if (options_.ms.freq==12) >>> mu = zeros(6,1); % hyperparameters >>> mu(1) = 0.57; >>> mu(2) = 0.13; >>> mu(3) = 0.1; >>> mu(4) = 1.5; >>> mu(5) = 5; >>> mu(6) = 5; >>> elseif (options_.ms.freq==4) >>> mu = zeros(6,1); % hyperparameters >>> mu(1) = 1; >>> mu(2) = 1; >>> mu(3) = 0.1; >>> mu(4) = 1; >>> mu(5) = 1; >>> mu(6) = 1; >>> else >>> disp('Warning: this code is only good for >>> monthly/quarterly data!!!') >>> return >>> end >>> >>> Stéphane >>> >>> ************************************************************** >>> Ce mel est a l'attention exclusive des >>> destinataires designes. >>> Il peut contenir des informations >>> confidentielles. >>> Si vous le recevez par erreur, merci d'en >>> informer sans delai l'expediteur. >>> >>> Le contenu de ce mel ne pourrait engager la >>> responsabilite de la Banque de France >>> que s'il a ete emis par une personne dument >>> habilitee agissant dans le strict >>> cadre des fonctions auxquelles elle est >>> employee et a des fins non etrangeres a ses attributions. >>> ************************************************************** >>> >> >> -- >> Sébastien Villemot >> CEPREMAP - Paris School of Economics >> Homepage: http://www.dynare.org/sebastien >> Landline phone: +33 1 40 77 49 90 >> SIP phone: sebastien.villemot(a)ekiga.net >> <mailto:sebastien.villemot@ekiga.net> >> PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/) >

2 1

Release of Dynare 4.2.0
by Sébastien Villemot 15 Feb '11

15 Feb '11

Dear Dynare users, We are pleased to announce the release of Dynare 4.2.0. This major release adds new features and fixes various bugs. The Windows package is already available for download. The Mac and Linux packages should follow soon. All users are strongly encouraged to upgrade. This release is compatible with MATLAB versions ranging from 6.5 (R13) to 7.11 (R2010b) and with GNU Octave versions 3.0.x and 3.2.x (support for GNU Octave 3.4.x is not complete and will be added in the next minor release). Here is the list of major user-visible changes: * New solution algorithms: - Pruning for second order simulations has been added, as described in Kim, Kim, Schaumburg and Sims (2008) [1,2] - Models under partial information can be solved, as in Pearlman, Currie and Levine (1986) [3,4] - New nonlinear solvers for faster deterministic simulations and steady state computation [5] * Dynare can now use the power of multi-core computers or of a cluster of computer using parallelization [6] * New features in the user interface: - A steady state file can now be automatically generated, provided that the model can be solved analytically, and that the steady state as a function of the parameters is declared with the new "steady_state_model" command [7] - For non-stationary models, Dynare is now able of automatically removing trends in all the equations: the user writes the equations in non-stationary form and declares the deflator of each variable. Then Dynare perform a check to determine if the proposed deflators are compatible with balanced growth path, and, if yes, then it computes the detrended equations [8] - It is now possible to use arbitrary functions in the model block [9] * Other minor changes to the user interface: - New primitives allowed in model block: normpdf(), erf() - New syntax for DSGE-VAR [10] - Syntax of deterministic shocks has changed: after the values keyword, arbitrary expressions must be enclosed within parentheses (but numeric constants are still accepted as is) * Various improvements: - Third order simulations now work without the "USE_DLL" option: installing a C++ compiler is no longer necessary for 3rd order - The HP filter works for empirical moments (previously it was only available for theoretical moments) - "ramsey_policy" now displays the planner objective value function under Ramsey policy and stores it in "oo_.planner_objective_value" - Estimation: if the "selected_variables_only" option is present, then the smoother will only be run on variables listed just after the estimation command - Estimation: in the "shocks" block, it is now possible to calibrate measurement errors on endogenous variables (using the same keywords than for calibrating variance/covariance matrix of exogenous shocks) - It is possibile to choose the parameter set for shock decomposition [11] - The diffuse filter now works under Octave - New option "console" on the Dynare command-line: use it when running Dynare from the console, it will replace graphical waitbars by text waitbars for long computations - Steady option "solve_algo=0" (uses fsolve()) now works under Octave * For Emacs users: - New Dynare mode for Emacs editor (contributed by Yannick Kalantzis) - Reference manual now available in Info format (distributed with Debian/Ubuntu packages) * Miscellaneous: - Deterministic models: leads and lags of two or more on endogenous variables are now substituted by auxiliary variables; exogenous variables are left as is [12] [1] Kim, J., S. Kim, E. Schaumburg and C.A. Sims (2008), "Calculating and using second-order accurate solutions of discrete time dynamic equilibrium models", Journal of Economic Dynamics and Control, 32(11), 3397-3414 [2] It is triggered by option "pruning" of "stoch_simul" (only 2nd order, not available at 3rd order) [3] Pearlman J., D. Currie and P. Levine (1986), "Rational expectations models with partial information", Economic Modelling, 3(2), 90-105 [4] http://www.dynare.org/DynareWiki/PartialInformation [5] http://www.dynare.org/DynareWiki/FastDeterministicSimulationAndSteadyStateC… [6] http://www.dynare.org/DynareWiki/ParallelDynare [7] See the entry for "steady_state_model" in the reference manual for more details and an example [8] http://www.dynare.org/DynareWiki/RemovingTrends [9] http://www.dynare.org/DynareWiki/ExternalFunctions [10] http://www.dynare.org/DynareWiki/DsgeVar [11] http://www.dynare.org/DynareWiki/ShockDecomposition [12] http://www.dynare.org/DynareWiki/AuxiliaryVariables On behalf of the Dynare team, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: sebastien.villemot(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

Re: [DynareDev] [Trac] #5: Implement explicit writing of first order conditions of Ramsey problem
by Trac Dynare 10 Feb '11

10 Feb '11

#5: Implement explicit writing of first order conditions of Ramsey problem ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: enhancement | Status: accepted Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * owner: sebastien => houtanb -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

Dynare 4.2 branch and imminent release
by Sébastien Villemot 07 Feb '11

07 Feb '11

Hi all, As you may have seen, I have created the git branch for the Dynare 4.2 release. I created release candidate #1 package for Dynare 4.2.0. You can download the Windows package at: http://www.dynare.org/sebastien/dynare-4.2.0-rc1-win.exe And the source package at: http://www.dynare.org/sebastien/dynare-4.2.0-rc1.tar.gz Please install and test this release candidate. You may want to test that the specific features you implemented are working fine, or that the models you are working on are correctly handled. My plan is to make the official release by the end of this week. Please give me your feedback as soon as possible, in order to have as few bugs as possible in the release. I reming you that during the lifetime of the 4.2 branch, every time you fix a bug in the master branch, you have the responsibility to backport this bugfix (if relevant) to the 4.2 branch. The git “cherry-pick” command of is the main tool for doing this. Don’t hesitate to contact me if you have any difficulty in backporting your bugfixes. Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Landline phone: +33 1 40 77 49 90 SIP phone: 87902(a)ekiga.net PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #138: Move Markov-Switching C-code under mex/sources, clarify the license
by Trac Dynare 04 Feb '11

04 Feb '11

#138: Move Markov-Switching C-code under mex/sources, clarify the license ----------------------------------+----------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Markov-Switching DLL | Version: Keywords: | ----------------------------------+----------------------------------------- And possibly give a better name to the module than "swz". -- Ticket URL: <https://www.dynare.org/trac/ticket/138> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #87: fix order of integration in univariate filter/smoother
by Trac Dynare 31 Jan '11

31 Jan '11

#87: fix order of integration in univariate filter/smoother --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/87> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #56: Faster smoother for large models
by Trac Dynare 31 Jan '11

31 Jan '11

#56: Faster smoother for large models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/56> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #158: Bug in smoother (more information needed)
by Trac Dynare 31 Jan '11

31 Jan '11

#158: Bug in smoother (more information needed) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/158> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #18: Clean-up, streamline and documente filter/smoother routines
by Trac Dynare 31 Jan '11

31 Jan '11

#18: Clean-up, streamline and documente filter/smoother routines ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: michel Type: enhancement | Status: accepted Priority: minor | Milestone: 4.3 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * priority: major => minor * milestone: 4.2 => 4.3 Comment: streamlining and cleanin-up is done. Remains internal documentation -- Ticket URL: <https://www.dynare.org/trac/ticket/18#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Huge emails on dynare commit list
by Sébastien Villemot 27 Jan '11

27 Jan '11

I have created new repositories on our server for hosting code from Tao Zha and Dan Waggoner, and in the process huge emails where sent by accident on the dynare commit lists. Some of you will not receive them because of size limits on their mailboxes. I apologize to those who received it. Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #37: Automatic generation of _steadystate.m file from initval block
by Trac Dynare 26 Jan '11

26 Jan '11

#37: Automatic generation of _steadystate.m file from initval block --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- The idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block. This would be particularly useful for estimating models for which the analytical form of the steady state is known. -- Ticket URL: <https://www.dynare.org/trac/ticket/37> Dynare <http://www.dynare.org> The Dynare project

1 11

Re: [DynareDev] [Trac] #24: Add Markov-Switching
by Trac Dynare 24 Jan '11

24 Jan '11

#24: Add Markov-Switching ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: major | Milestone: 4.3 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/24#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 21 Jan '11

21 Jan '11

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: closed Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: reopened => closed * resolution: => fixed Comment: Wiki fixed on 2011-01-21 -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:11> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #126: Include Dynare++'s "dynare_simul.m" in the Dynare package
by Trac Dynare 20 Jan '11

20 Jan '11

#126: Include Dynare++'s "dynare_simul.m" in the Dynare package --------------------------------------+------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Build system / Packaging | Version: 4.1.2 Keywords: | --------------------------------------+------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/126> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #145: when cross-compiling, the host prefix is not added to "ar"
by Trac Dynare 20 Jan '11

20 Jan '11

#145: when cross-compiling, the host prefix is not added to "ar" --------------------------------------+------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: trivial | Milestone: Component: Build system / Packaging | Version: 4.1.3 Keywords: | --------------------------------------+------------------------------------- When building a static library (as in preprocessor/macro), the build system will always use "ar" (instead of "i686-w64-mingw32-ar" for example). In most cases this is not a problem. The problem can happen if one has only the cross-compiling binutils, but not the native binutils, as for example in a Cygwin install where only the packages listed on the wiki page are installed. -- Ticket URL: <https://www.dynare.org/trac/ticket/145> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 18 Jan '11

18 Jan '11

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): The previous comment should read: Testsuite crashes '''fixed''' as of ce072236284481de7b3cfff55f55507c6ebb605e. Wiki still needs updating. -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:10> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 18 Jan '11

18 Jan '11

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Testsuite crashes as of ce072236284481de7b3cfff55f55507c6ebb605e. Wiki still needs updating. -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:9> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #128: Fix derivatives of STEADY_STATE operator w.r.t. parameters in dynamic model
by Trac Dynare 14 Jan '11

14 Jan '11

#128: Fix derivatives of STEADY_STATE operator w.r.t. parameters in dynamic model --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- The fix is to add a new input argument to the params_deriv file, which would contain the derivatives of the steady state w.r.t. parameters (it is the responsibility of the caller to provide them). -- Ticket URL: <https://www.dynare.org/trac/ticket/128> Dynare <http://www.dynare.org> The Dynare project

3 4

modifications to the smoother
by Michel Juillard 13 Jan '11

13 Jan '11

I just uploaded to unstable an important modification to the code for the Kalman smoother. Re-factoring existing code, correcting some bugs for the diffuse smoother (nonstationary models), and eliminating specialization of the code meant to improve efficiency. In the future, we will expand the existing DLL for likelihood for the smoother and dealing with special cases. Please, report any problem that you could encounter with the new code. Best, Michel

1 0

Fwd: Re: Dynare Snapshot 12/19/2010
by Sébastien Villemot 12 Jan '11

12 Jan '11

Hi all, I attach a mail that I received from Johannes Pfeifer, which raises 3 problems and makes 2 suggestions. I pushed a fix for problem #2 (varlist_indices.m) and I can’t reproduce problem #3 (related to USE_DLL) even under Windows. Concerning problem #1 (empirical autocorrelations), Johannes is right in the sense that - with the current code - one can get an autocorrelation that is not within [-1,1], because the covariance on the numerator does not span the same sample than the variances on the denominator; the fix that he suggests would fix this. On the other hand, estimators of the autocorrelation coefficients are known to be biased in finite samples (and there is no easy way of fixing this), so applying Johannes’ change would just consist in moving from a biased estimator to another biased estimator (and I don’t know how the bias is changed). These estimators are only asymptotically consistent, and getting a weird value is the indication that the sample is too small and that more simulations should be done. What is your opinion about this issue, and about the two suggestions (options for no IRF files, and NaN/Inf treatment in estimation) ? Best, -- Sébastien Villemot CEPREMAP - Paris School of Economics Homepage: http://www.dynare.org/sebastien Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 2

[Trac] #75: Fix command "calib" or remove it
by Trac Dynare 04 Jan '11

04 Jan '11

#75: Fix command "calib" or remove it --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The "calib" command (and its associated command "calib_var") are recognized by the preprocessor, but are probably not working, and are not documented in the reference manual. This should be fixed, or the commands be removed. -- Ticket URL: <https://www.dynare.org/trac/ticket/75> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #95: the "simul" option of "stoch_simul" simulates on more periods than required
by Trac Dynare 02 Jan '11

02 Jan '11

#95: the "simul" option of "stoch_simul" simulates on more periods than required --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: trivial | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The point is that the oo_.exo_simul vector has length options_.periods+M_.maximum_lag+M_.maximum_lead (see make_ex_.m). This makes sense in a deterministic context, but in a stochastic context there it should only be of length options_.periods. This makes the oo_.endo_simul of length 2*M_.maximum_lag+options_.periods+M_.maximum_lead (because it adds initial conditions), while it should be of length M_.maximum_lag+options_.periods. This is not a big issue since one can just truncate the extra periods, but this confuses some users. -- Ticket URL: <https://www.dynare.org/trac/ticket/95> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #78: Problem with derivatives of power function at point zero
by Trac Dynare 17 Dec '10

17 Dec '10

#78: Problem with derivatives of power function at point zero --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- There is currently a problem with the derivatives of the power function f(x)=x^p^ at the point x=0. The power function f(x)=x^p^ well defined for x>0 and for any p, since f(x)=e^p*ln(x)^. The domain of definition of this function can be extended to x=0 with the following rules when p>0: * f(0)=0 * f is differentiable k times at x=0, where k is the integer part of p, and f'^k^=0 And when p is an strictly positive integer, the function is differentiable at any order, and its derivative at zero is zero. When p is a constant, the preprocessor computes the right value of the derivatives at x=0, using simplifications rules. But when p is a parameter, the preprocessor will not give the right value for integer values of p. Currently the derivation rule is applied by the preprocessor, the k-th derivative of f(x) is equal to: p*(p-1)*...*(p-k+1)*x^p-k^ So when p is an integer, the (p+1)-th derivative computed at x=0 will give a NaN (0 times infinity), while it ought to be zero. This problem typically arises in models with adjustment costs where the curvature (the exponent) of the cost is a integer parameter, and the cost is zero at steady state. The solution is probably to create, in the preprocessor, a new operator called "derivative of power function at order k". This operator would output a code like that in the M-file: {{{ dxp=deriv(x,p,k) % The k-th derivative of x^p if (p > 0) && (abs(p - round(p)) < 1e-12 && k >= p dxp = 0; else dxp = x^(p-k); for i=1:k-1 dxp = dxp*p; p = p-1; end end }}} -- Ticket URL: <https://www.dynare.org/trac/ticket/78> Dynare <http://www.dynare.org> The Dynare project

1 7

[Trac] #156: distclean doesn't work if Dynare was built with --disable-octave
by Trac Dynare 15 Dec '10

15 Dec '10

#156: distclean doesn't work if Dynare was built with --disable-octave --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- This seems to be a problem with the options of the build system. -- Ticket URL: <https://www.dynare.org/trac/ticket/156> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] Fwd: Re: SLICOT Library
by stephane.adjemian＠gmail.com 14 Dec '10

14 Dec '10

Hi George, I plan to (for dynare>=4.3) entirely rewrite the kalman filter routines (matlab codes) to allow for unexpected structural breaks. I use Slicot because this library provides a lot of utilities for handling state space models and evaluating kalman filters. For instance, I use a solver for the discrete Riccatti equations, and use the solution for initializing the kalman filter. This gives a much more stable evaluation of the likelihood (also the evaluation is much faster). This evaluation is biased but its variance is smaller. As a first approximation (for large models) I use this trick when looking for the posterior mode (or maximum likelihood). This gives a very good initial guess when estimating the posterior mode. I will also use the library to reduce the size of the state space model and for comparison purposes. Best, Stéphane. George Perendia <george(a)perendia.orangehome.co.uk> writes: > Hi Stephane > From the email below I gather you are planning to use SLICOT for some work with KF. > I was just intrigued and wandered if you can shed me some light on that or send me some existing paper-work if poss and you have a moment for that. > > Best regards > George > > -------- Original Message -------- > Subject: Re: SLICOT Library > Date: Mon, 13 Dec 2010 10:24:07 +0100 > From: Sébastien Villemot <sebastien.villemot(a)ens.fr> > To: George Perendia <george(a)perendia.orangehome.co.uk> > > George Perendia <george(a)perendia.orangehome.co.uk> writes: > >> I noticed a new sub-directory of Dynare mex files - SLICOT Library. >> What is going to be the main use of the control system SLICOT Library within >> Dynare that is in mex slicot directory and how will it be accessed? Are there >> any wiki pages on it? > > SLICOT is a multi-purpose optimal control library written in Fortran, > see http://www.slicot.org/ > > Stéphane is now using it in some extensions of the Kalman filter. If you > want more details on that, please ask him directly. > > We included it in Dynare distribution (instead of simply making Dynare > depend on it), because there is no pre-packaged version of this library > (neither in Debian/Ubuntu nor in Cygwin). > > Best, -- Stéphane Adjemian Université du Maine, GAINS & CEPREMAP http://www.dynare.org/stepan

1 0

[Trac] #154: Change build process to make libslicot optional on Mac OS X
by Trac Dynare 13 Dec '10

13 Dec '10

#154: Change build process to make libslicot optional on Mac OS X --------------------------------------+------------------------------------- Reporter: houtanb | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- XCode doesn't provide a Fortran compiler so Mac users will either have to find one precompiled or compile it on their own. Hence, libslicot should be optional in the build process. -- Ticket URL: <https://www.dynare.org/trac/ticket/154> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #155: GraphvizDigraph has been removed from recent Boost versions
by Trac Dynare 13 Dec '10

13 Dec '10

#155: GraphvizDigraph has been removed from recent Boost versions --------------------------+------------------------------------------------- Reporter: michel | Owner: ferhat Type: bug | Status: new Priority: critical | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- It appears that GraphvizDigraph was removed from Boost in version 1.43. See https://svn.boost.org/trac/boost/ticket/4762 GrahphvizDigraph is used in MinimumFeedbackSet.hh (line 58) and in ModelTree.cc (line 513) Boost version 1.45 is available in Redhat version 6, but only version 1.42 is available in Debian testing/unstable -- Ticket URL: <https://www.dynare.org/trac/ticket/155> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] Problems building Dynare on RH ES4
by Michel Juillard 10 Dec '10

10 Dec '10

Dear Paul, thank you very much for reporting the problem. It appears that GraphvizDigraph was removed from Boost in version 1.43. See https://svn.boost.org/trac/boost/ticket/4762 As Debian is still at version 1.42, we weren't aware from the problem. We are going to fix this. In the meantime, you should try to get version 1.42 of the Boost graphic library. Best, Michel PS. The Dynare forum is a better way to contact us, rather than the email of the webmaster. m On 12/10/2010 04:49 PM, michaud(a)umich.edu wrote: > You are receiving this mail because Paul Michaud > michaud(a)umich.edu > is sending feedback about the site administered by you at http://www.dynare.org. > The message sent was: > > Hi, I'm attempting to build Dynare 4.1.3 from source in a Red Hat Enterprise Linux ES release 4 (Nahant Update 8) environment. To configure I use the following command: ./configure --prefix=/software/dynare/v4.1.3 --with-boost=/software/Boost/v1.45.0 --with-matlab=/software/matlab_2009b MATLAB_VERSION=R2009b According to the configure logs a "make" should build the Dynare preprocessor. Said "make" builds the libmicro.a library just fine. However, in the preprocessor build step it chokes building dynare_m-ModelTree.o. It's complaint is that (starting on line 58) in the MinimumFeedbackSet.hh include file (used by ModelTree.cc) GraphvizDigraph is not declared. The same issue comes up on line 513 of ModelTree.cc. There are some other bits as well but this appears to be the main catalyst. I can forward you the make output but didn't want to clutter up this initial email with all that goo. :-) Thanks much for any help that you can provide! :-) Paul ============================================================================ Paul Michaud Research Computing Stephen M. Ross School of Business at the University of Michigan Email: michaud(a)umich.edu Phone: 734-763-5677 Fax: 734-936-6029 ============================================================================ > > >

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 10 Dec '10

10 Dec '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: feature | Status: closed Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: assigned => closed * resolution: => fixed Comment: Implemented in bytecode in 97664607b2f839caa2e733d72655307dc6023ea0 -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:12> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #73: The macroprocessor fails when the file ends with @#endif or @#endfor without a new line at the EOF
by Trac Dynare 06 Dec '10

06 Dec '10

#73: The macroprocessor fails when the file ends with @#endif or @#endfor without a new line at the EOF --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/73> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #22: Expand specification of priors (i.e. priors on relative variances between 2 shocks)
by Trac Dynare 03 Dec '10

03 Dec '10

#22: Expand specification of priors (i.e. priors on relative variances between 2 shocks) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: michel Type: feature | Status: assigned Priority: major | Milestone: 4.3 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * owner: => michel * status: new => assigned * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/22#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #17: Update user guide
by Trac Dynare 03 Dec '10

03 Dec '10

#17: Update user guide ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: michel Type: enhancement | Status: assigned Priority: major | Milestone: 4.3 Component: Documentation | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by sebastien): * owner: tommaso => michel * status: new => assigned * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/17#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #5: Implement explicit writing of first order conditions of Ramsey problem
by Trac Dynare 03 Dec '10

03 Dec '10

#5: Implement explicit writing of first order conditions of Ramsey problem ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: enhancement | Status: accepted Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #99: too many graphs crash Matlab
by Trac Dynare 03 Dec '10

03 Dec '10

#99: too many graphs crash Matlab --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- A large number of busy graphs (34 in my example) crash Matlab r2010a under Linux 64-bit I still need to upload the example to test it in different versions of Matlab -- Ticket URL: <https://www.dynare.org/trac/ticket/99> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #53: Clean up and speed up simult_.m
by Trac Dynare 18 Nov '10

18 Nov '10

#53: Clean up and speed up simult_.m --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/53> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #153: parameters with lead or lag
by Trac Dynare 18 Nov '10

18 Nov '10

#153: parameters with lead or lag --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.3 Keywords: | --------------------------+------------------------------------------------- In model, a parameter followed by a lead or a lag construct doesn't trigger an error, but M_.maximum_lead or M_.maximum_lag is affected if this lead or lag > 2. -- Ticket URL: <https://www.dynare.org/trac/ticket/153> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #40: Test M_.params at the top of the main functions.
by Trac Dynare 17 Nov '10

17 Nov '10

#40: Test M_.params at the top of the main functions. --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN). -- Ticket URL: <https://www.dynare.org/trac/ticket/40> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #103: bug in dealing with <fname>_steadystate.m functions that modify parameters
by Trac Dynare 15 Nov '10

15 Nov '10

#103: bug in dealing with <fname>_steadystate.m functions that modify parameters --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The changes to M_.params introduced in <fname>_steadystate.m functions are not taken into accounts by calling functions that obtain M_ as argument and not as global variable. Need to add M_.params = evalin('base','M_.params'); after each call to <fname>_steadystate.m function -- Ticket URL: <https://www.dynare.org/trac/ticket/103> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #140: set_dynare_threads function fails on MATLAB < 7.2
by Trac Dynare 15 Nov '10

15 Nov '10

#140: set_dynare_threads function fails on MATLAB < 7.2 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- This is because setenv() was introduced in MATLAB 7.2. We need to find a workaround for older versions. Currently Dynare crashes on these versions for that reason. -- Ticket URL: <https://www.dynare.org/trac/ticket/140> Dynare <http://www.dynare.org> The Dynare project

1 2

Dynare internal documentation
by Michel Juillard 15 Nov '10

15 Nov '10

I have uploaded to GIT the beginning of an internal documentation for Dynare. It is written in emacs org-mode and export easily to HTML, Latex and PDF. It is located in ./doc/internals/dynare-internals.org Sébastien is going to include it in the automatic build system of Dynare and it will be automatically updated from GIT on the web site (or maybe rather on the Wiki as it is just the beginning of something). Please, comment on the format that can surely be improved upon and suggest practical alternatives. Don't hesitate to contribute as well. Best, Michel

2 1

Re: [DynareDev] [Trac] #13: Add estimation with unexpected structural change
by Trac Dynare 12 Nov '10

12 Nov '10

#13: Add estimation with unexpected structural change ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: stepan Type: feature | Status: assigned Priority: major | Milestone: 4.3 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/13#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #111: Add the possibility to solve underdetermined models
by Trac Dynare 12 Nov '10

12 Nov '10

#111: Add the possibility to solve underdetermined models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- When the Blanchard-Kahn conditions are not satisfied because the model is underdetermined, it is possible to select a solution among the infinity of solutions, provided we impose more restrictions. We can implement the solution of Lubik and Schorfheide, “Testing for Indeterminacy:An Application to U.S. Monetary Policy” (AER, 2004), see http://ideas.repec.org/p/jhu/papers/480.html -- Ticket URL: <https://www.dynare.org/trac/ticket/111> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #26: Nonlinear estimation (was: Add particle filter for 2nd order estimation)
by Trac Dynare 12 Nov '10

12 Nov '10

#26: Nonlinear estimation ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 5.0 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: 4.3 => 5.0 -- Ticket URL: <https://www.dynare.org/trac/ticket/26#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #55: Finalize the generic parallelization system
by Trac Dynare 03 Nov '10

03 Nov '10

#55: Finalize the generic parallelization system --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- See http://www.dynare.org/DynareWiki/ParallelDynare for the remain subtasks. -- Ticket URL: <https://www.dynare.org/trac/ticket/55> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #144: implement solve_algo=0 for Octave
by Trac Dynare 28 Oct '10

28 Oct '10

#144: implement solve_algo=0 for Octave --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- fsolve() has a slightly different syntax under Octave Need to adapt dynare_solve.m -- Ticket URL: <https://www.dynare.org/trac/ticket/144> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 28 Oct '10

28 Oct '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Replying to [comment:7 sebastien]: > Crashes in testsuite fixed as of 1aceb504fdd722c26697113be48ee541d9e09556 No, the crash is still here. -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:8> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 28 Oct '10

28 Oct '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: feature | Status: assigned Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * owner: houtanb => ferhat * status: accepted => assigned -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:11> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #130: Console mode
by Trac Dynare 28 Oct '10

28 Oct '10

#130: Console mode --------------------------+------------------------------------------------- Reporter: stepan | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- Add an option to the dynare command for the console mode. This option may be called "console", "terminal" or "term", if used options_.console_mode would be set to 1 and graphical waitbars are replaced by text waitbars. The matlab code is ready (ie one can write options_.console_mode=1; in the mod file before the estimation command), Sébastien only needs to add something in the preprocessor. -- Ticket URL: <https://www.dynare.org/trac/ticket/130> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 27 Oct '10

27 Oct '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Crashes in testsuite fixed as of 1aceb504fdd722c26697113be48ee541d9e09556 -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:7> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 22 Oct '10

22 Oct '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Replying to [comment:5 sebastien]: > - As of 5f0dac24bf0e7b65fdc43e21a5dc7eeb1ae92776, the test file block_bytecode/ls2003.mod crashes under Octave Fixed in 39718c86456246f0950080201e6ca910f47ba176 > - We should probably swap values 5 and 8 for solve_algo, for consistency with Dynare 4.1 Fixed in 39718c86456246f0950080201e6ca910f47ba176 > - The new values for stack_solve_algo and solve_algo (in combination with block/bytecode) need to be documented on the wiki and in the reference manual (on the wiki, we should keep separate sections on Dynare 4.1 and Dynare 4.2) Fixed in reference manual in 55c6089deb3873f5fdcb0874db076aac569b288c Remains to be done: - update wiki pages - fix crash in new testsuite -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:6> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 21 Oct '10

21 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: closed Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: Reference manual entry added in 2f9a6ff9f4759f82f9866424f72d0e5efb8fcf19 -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:9> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 21 Oct '10

21 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): I added qzcomplex Oct-file in 69fc0e320bab92ab423631168af4f40c1b038d86. I decided to rewrite it from scratch, instead of re-using the one distributed by Sims, because Sims did not write it. He is not completely sure about who did. And it was a good opportunity to learn how to write Oct-files. The partial information routines now give the same result under MATLAB and Octave. -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:8> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #21: Add partial information
by Sébastien Villemot 20 Oct '10

20 Oct '10

Hi George, George Perendia <george(a)perendia.orangehome.co.uk> writes: > we explored alternative paths and it looks like we need to add a > complex QZ on lines of the Matlab to Octave. If I understand correctly, you need a complex QZ decomposition at line 156 of partial_information/PI_gensys.m, where you call the qz() primitive (and only there). Note for other developers: the qz() primitive under Octave delivers only the *real* generalized Schur decomposition. > C Sims' site provides such wrapper for octave version of gensys.m > based on Lapack zgges.f: > http://sims.princeton.edu/yftp/gensys/Octave/ > > but that is using Octave specific mkoctfile compilation and octave specific .c interface. > > Considering we are not using mkoctfile, and it may not be acceptable > within Dynare, would it be ok if we take up an alternative path to > rewrite mjdgges.c as an additional qzzges.c (laving mjdgges as is of > course) that returns complex on the same lines as Matalb qz() does, > and add it to the e.g. qz subdirectory where mjdgges currenlty resides > (though the zdgges.f still needs to be tested if it does the right > trick but this would be the way to test it too)? I think that the easiest way to go is to incorporate Sims' qzcomplex oct-file into Dynare, provided that Sims agrees on putting it under the GPL (which should probably not be a problem). The fact that this uses mkoctfile is not a problem: it is possible to emulate this command with the build system as we did for the mex command. The fact that it uses Octave specific Oct-interface is not a problem: we can build this DLL only for Octave (and therefore with a ".oct" extension), since it is useless under MATLAB. And of course we would put it under mex/octave. I agree with you that this will force users to have compiled DLLs in order to use your code, but there are already many other features of Dynare in that case (k-order, bytecode...). If you agree with that line of work, I will contact Sims to ask for permission of including his code under the GPL into Dynare, and then I will make the necessary changes to the build system. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 3

[Trac] #131: histval is broken in models with lag > 1
by Trac Dynare 20 Oct '10

20 Oct '10

#131: histval is broken in models with lag > 1 --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: critical | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- initialization doesn't take auxiliary variables into account initial matrix has wrong dimension -- Ticket URL: <https://www.dynare.org/trac/ticket/131> Dynare <http://www.dynare.org> The Dynare project

1 3

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 20 Oct '10

20 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by george): Replying to [comment:5 george]: > > The problem with the difference seem to stem from the difference in QZ calculation b/w Octave and matlab. I will follow this up! modified PI_gensys to use C.Sims' Lapack zgges based qzcomplex() qz decomposition routine under Octave which gives nearly identical complex results to Matlab QZ (except for the transpose of q matrix and few sign changes in the output matrices) -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:7> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #19: Add tool to automatically write a stationary version of the model, given trends supplied by user
by Trac Dynare 18 Oct '10

18 Oct '10

#19: Add tool to automatically write a stationary version of the model, given trends supplied by user ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: closed Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: See http://www.dynare.org/DynareWiki/RemovingTrends Implemented in 894155be8834724a6999af502b124ed215b8d661 -- Ticket URL: <https://www.dynare.org/trac/ticket/19#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 15 Oct '10

15 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Replying to [comment:3 sebastien]: > Two minor issues to be solved (among others): > * the file matlab/disclyap_fast.m has no copyright: this should be clarified Done in a5b88195189eb694b2c8fd2cae65ed29818ee673 > * the files matlab/partial_information/{qzswitch,qzdiv}.m are redundant with the versions in matlab/qz. These files should be deleted once the PI code relies on mjdgges. Files removed in 44b268ec6742f0500b6627c029f7653b0a572e13. As of a5b88195189eb694b2c8fd2cae65ed29818ee673, the code does not give the same results under Octave and MATLAB. -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:4> Dynare <http://www.dynare.org> The Dynare project

3 2

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 15 Oct '10

15 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Documentation in reference manual needs to be added, based on the wiki page: http://www.dynare.org/DynareWiki/PartialInformation -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:6> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 14 Oct '10

14 Oct '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by george): The problem with the difference seem to stem from the difference in QZ calculation b/w Octave and matlab. I will follow this up! -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

Release of Dynare 4.1.3
by Sébastien Villemot 14 Oct '10

14 Oct '10

I have just released Dynare 4.1.3, see the announcement at : http://www.dynare.org/news/release-of-dynare-4.1.3 This is probably the latest release in the 4.1 series. -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #129: Give more explicit error messages for purely backward/forward models
by Trac Dynare 13 Oct '10

13 Oct '10

#129: Give more explicit error messages for purely backward/forward models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.1.2 Keywords: | --------------------------+------------------------------------------------- See for example: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2769 -- Ticket URL: <https://www.dynare.org/trac/ticket/129> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 12 Oct '10

12 Oct '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: reopened Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: closed => reopened * resolution: fixed => Comment: - As of 5f0dac24bf0e7b65fdc43e21a5dc7eeb1ae92776, the test file block_bytecode/ls2003.mod crashes under Octave - We should probably swap values 5 and 8 for solve_algo, for consistency with Dynare 4.1 - The new values for stack_solve_algo and solve_algo (in combination with block/bytecode) need to be documented on the wiki and in the reference manual (on the wiki, we should keep separate sections on Dynare 4.1 and Dynare 4.2) -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 11 Oct '10

11 Oct '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: closed Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by ferhat): * status: accepted => closed * resolution: => fixed Comment: - Extends the algorithms compatible with bytecode to compute the steady- state. The new values for solve_algo are: * 0: fsolve * 1: solve1 * 2, 4: solve1 + block decomposition * 3: csolve * 5: LU decomposition with UMFPack (method handling sparse matrix in Matlab) * 6: GMRES * 7: BiCGStab * 8: bytecode own solver (use gaussian elimination + sparse matrix) -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Dynare 4.2 release goals and schedule
by Sébastien Villemot 11 Oct '10

11 Oct '10

Hi, I summarize in this e-mail the main release goals for Dynare 4.2, with the name of the responsible person(s) and the associated ticket numbers. Note that there are many other tickets – in particular bugs which need to be fixed – but I only list here the outstanding intended new features : - Symbolic computation of the first order conditions of the Ramsey problem (Sébastien) [#5] - Use of a seed to make estimation deterministic (Michel, Stéphane) [#85] - Estimation with unexpected structural changes (Stéphane) [#13] - Partial information (George) [#21] - Markov-Switching BVAR (Houtan, Michel) [#24] - Automatic generation of the stationary model, given the trends (Houtan) [#19] - Local identification (Marco) [#31] - Parallelization system (Marco, Sébastien) [#55] - Constrained parameters for OSR (Michel) [#58] - Possibility of using the bytecode representations for most tasks (Ferhat, Sébastien) [#11] - User guide: refresh outdated parts, add new chapter on optimal policy (Tommaso, Michel) [#17] The goal is to release the 4.2 version by the beginning of november, which means that the various features should be ready by mid-october. Note that by “ready” I mean that the features must be working reasonably well, have an interface in the MOD-file, be documented (at least on the wiki, preferably in the reference manual), and come with test files in the appropriate directory. Of course I can help you concerning these various aspects, in particular for the interface (which require preprocessor changes) and for the build system. Let me know if you think that you cannot achieve completion of the features that you are responsible for by the mid-october deadline. We will then decide whether to postpone the feature for 4.3 or to delay the release of 4.2. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

4 4

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 07 Oct '10

07 Oct '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Implemented for USE_DLL in 078574ee4a6d3beb249b9a288f275a1ed43f4906 -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:10> Dynare <http://www.dynare.org> The Dynare project

1 0

Updates for Windows users
by Sébastien Villemot 28 Sep '10

28 Sep '10

Hi, Recently, the MinGW packages for 32-bit and 64-bit have entered Cygwin. This will facilitate the life of Windows users and developers of Dynare in two ways: - the compilation of Dynare under Windows can now be entirely done under Cygwin, without the need to download an external compiler; the Windows section on the wiki page has been correspondingly updated: http://www.dynare.org/DynareWiki/BuildingDynareFromSource - the "use_dll" option also benefits from this change, and in particular it is possible to use GCC under 64-bit MATLAB with this option. An updated "mexopts.bat" file, using the new MinGW packages, is available on the following page: http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #139: Rename "cygwin" option in "mingw"
by Trac Dynare 28 Sep '10

28 Sep '10

#139: Rename "cygwin" option in "mingw" --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- The name of the option is misleading since even under Cygwin we internally use MinGW embedded within GCC 3. The old option should give an error message pointing to the new one. Example mexopts.bat should be given for at least 3 cases (in the package and in the wiki): - Cygwin + GCC 3 (hence 32-bit) - MinGW 32-bit (probably for TDM build) - MinGW 64-bit (probably for TDM build) -- Ticket URL: <https://www.dynare.org/trac/ticket/139> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #132: forecast has a bug in models with lag > 1
by Trac Dynare 28 Sep '10

28 Sep '10

#132: forecast has a bug in models with lag > 1 --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/132> Dynare <http://www.dynare.org> The Dynare project

1 2

strvcat() replaced by char()
by houtan 27 Sep '10

27 Sep '10

Hi All, Fixing ticket #93 entailed the replacement of all instances of the deprecated Matlab function strvcat() with char(). Unfortunately, these two functions are slightly different in that char() does not ignore the empty string as strvcat() does. Hence, code that initializes a character array either with '' or with [], would have all arguments beginning one space later in the array (position 2 as opposed to position 1). You can see the difference in Matlab by doing the following. 1) charArr = []; (or charArr = '';) 2) strvcat(charArr,'a','b') 3) char(charArr,'a','b') After creating commit a20bc07fdf99456c83fa54ccd658575c1d4baa71, I ran make check, which worked fine. However, as the change was nontrivial and touched a lot of .m files, if you have the time it would probably be best to look at the commit to see if any of your project files were effected. If they were, please check to make sure that the change does not affect the way it operates. Please note that inherent in this commit is the assumption that no arguments to char() from positions 2:end are empty. If they are and you were relying on strvcat() to skip them, this will have to be fixed as well. Best, Houtan

1 0

[Trac] #93: Replace functions deprecated in MATLAB 7.10 (R2010a)
by Trac Dynare 27 Sep '10

27 Sep '10

#93: Replace functions deprecated in MATLAB 7.10 (R2010a) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Among others, the following functions are deprecated in MATLAB 7.10 (R2010a), but still work: {{{isstr, setstr, str2mat, strread, strvcat, textread}}} Every occurrence of these functions should be replaced in the M-files and in the preprocessor, for compatibility with future versions of MATLAB. See http://www.mathworks.com/access/helpdesk/help/techdoc/rn/br_bpq8-1.html#bsd… for their replacements. -- Ticket URL: <https://www.dynare.org/trac/ticket/93> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #69: Update or remove code for multithreaded DLL using OpenMP
by Trac Dynare 27 Sep '10

27 Sep '10

#69: Update or remove code for multithreaded DLL using OpenMP --------------------------+------------------------------------------------- Reporter: sebastien | Owner: stepan Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Concerns directories: mex/sources/threads matlab/threads and files: matlab/dynare_config.m mex/sources/build_matlab_multithread.m Removed from 4.1 branch in r3259 -- Ticket URL: <https://www.dynare.org/trac/ticket/69> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #125: fix nograph option in forecast instruction
by Trac Dynare 24 Sep '10

24 Sep '10

#125: fix nograph option in forecast instruction --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/125> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #137: remove occurences of mexErrMsgTxt() in all MEX files
by Trac Dynare 24 Sep '10

24 Sep '10

#137: remove occurences of mexErrMsgTxt() in all MEX files --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: critical | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- This function throws a C++ exception, which is not handled correctly by MinGW for 64-bit (at the current time). It appears that the benefits of using MinGW on Windows 64 are greater than the inconvenience of not using that function. In case of error, MEX files should print a meaningful message with mexPrintf(), and then return control to MATLAB (with return()). A new output argument of the MEX file should be dedicated to informing MATLAB of the error condition (the output argument can be 0 in case of success, 1 in case of error). The MATLAB code should check that argument, and in case of failure should run "error('MEX failed')" to interrupt the execution of the code. Note that it is still possible to use C++ exceptions inside the MEX function (as is currently done in k_order_perturbation), so that all error conditions can be catched by the top-level mexFunction(). -- Ticket URL: <https://www.dynare.org/trac/ticket/137> Dynare <http://www.dynare.org> The Dynare project

1 3

Re: [DynareDev] =SWZ dll
by Sébastien Villemot 23 Sep '10

23 Sep '10

Michel Juillard <michel.juillard(a)ens.fr> writes: > since the latest changes, I have an error when trying to compilte SWZ dll: > > michel@michel-lat3:~/dynare/git/dynare/mex/build/matlab/swz$ make > make: *** No rule to make target > ../../../../matlab/swz/c-code/mex/mex_top_level.c', needed by > mex_top_level.o'. Stop. > > for some reason it stil uses mex_top_level.c as implicit prerequisite for > mex_top_level.o instead of mex_top_level.cc It’s a problem of automake. You need to do a "make distclean", then re-configure, then make. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #101: Preprocessor crashes when some dynamic variables appear only in unused model local variables
by Trac Dynare 23 Sep '10

23 Sep '10

#101: Preprocessor crashes when some dynamic variables appear only in unused model local variables --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.1 Keywords: | --------------------------+------------------------------------------------- See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2592 The fix is probably to add calls to ExprNode::collectVariables() on model local variables from DynamicModel::computeDerivIDs() -- Ticket URL: <https://www.dynare.org/trac/ticket/101> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #105: Support normcdf(), asinh(), acosh(), atanh() for USE_DLL+MSVC combination
by Trac Dynare 21 Sep '10

21 Sep '10

#105: Support normcdf(), asinh(), acosh(), atanh() for USE_DLL+MSVC combination --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- This would be particularly useful for Windows/64 users, since they don't have the Cygwin option. -- Ticket URL: <https://www.dynare.org/trac/ticket/105> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #98: Implement STEADY_STATE operator with USE_DLL and bytecode options
by Trac Dynare 20 Sep '10

20 Sep '10

#98: Implement STEADY_STATE operator with USE_DLL and bytecode options --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.1 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/98> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #45: Implement resid() with "block" option without "bytecode"
by Trac Dynare 17 Sep '10

17 Sep '10

#45: Implement resid() with "block" option without "bytecode" --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/45> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #11: Allow for the possibility of using the bytecode representation of the model for any task
by Trac Dynare 10 Sep '10

10 Sep '10

#11: Allow for the possibility of using the bytecode representation of the model for any task ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: ferhat Type: enhancement | Status: accepted Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Almost done. We plan a change in the semantics of stack_solve_algo. Currently, values 0 and 1 actually implement the same algorithm (sim1/simk don’t actually implement the original relaxation algorithm). We propose to associate to value 1 the original relaxation algorithm, which will be available in bytecode at first (slower, but less memory-consuming). -- Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

MATLAB R2010b released
by Sébastien Villemot 10 Sep '10

10 Sep '10

See: http://www.mathworks.com/products/new_products/latest_features.html?s_cid=0… -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 2

Parallel Dynare
by Sébastien Villemot 10 Sep '10

10 Sep '10

Hi, I updated the wiki page concerning the generic parallelization scheme of Dynare. http://www.dynare.org/DynareWiki/ParallelDynare Please verify that I did not forget anything we discussed during our meeting. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 2

Re: [DynareDev] [Trac] #14: Create a database of old and new example MOD files
by Trac Dynare 03 Sep '10

03 Sep '10

#14: Create a database of old and new example MOD files ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.3 Component: Documentation | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by michel): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/14#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] Compiling Dynare under Windows
by Sébastien Villemot 03 Sep '10

03 Sep '10

On Fri, Sep 03, 2010 at 10:06:48AM +0100, George Perendia wrote: > PS: And what about existing cygwin installation with mingw in > C:\cygwin\usr\i686-pc-mingw32 > Do we still need to upgrade mingw? What is this installation ? If it is a custom installation, then just delete it. There is also a MinGW provided by Cygwin, but it is deficient and uses an old GCC version (3). In any case, you need to install the MinGW mentionned on the wiki page. And don’t forget to clean your PATH if it contains other installations of MinGW. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

2 1

Re: [DynareDev] Compiling Dynare under Windows
by Sébastien Villemot 03 Sep '10

03 Sep '10

On Fri, Sep 03, 2010 at 09:59:12AM +0100, George Perendia wrote: > This looks good and easier for a novice to use. > > 1) What about the old user requirements for windows (cygwin) not > listed any more such as: > * {{{gcc}}}, {{{gcc-g++}}} > * {{{gcc-mingw}}}, {{{gcc-mingw-g++}}} > * {{{gcc4}}}, {{{gcc4-g++}}} and {{{gcc4-gfortran}}} > * {{{readline}}} > * {{{libhdf5-devel}}} > > Are they not needed any more if one uses Mingw? No, they are not needed anymore for compiling Dynare with MinGW. But keeping them is not a problem either. > 2) What happened to Git users such as our development team? Do we > continue to use Git to download? I suppose we do but what then about > the precompiled libraries, will they be updateable via git too? Nothing has changed regarding Git. We still use it for the development of the Dynare source code. Concerning the precompiled binaries, I don’t plan to use a git repository for them, since they are going to change very rarely. Actually they’re going to change only if we introduce a new dependency for Dynare (for example when we added the GSL for the Markov-Switching code), or if we want to upgrade versions there. I will send an e-mail on the list if I update them. > 3) GitHowTo (still) suggests using "pull" to download but yuo say > you prefer us to use Fetch&Rebase. F&R may be easier to control from > the PM view but it does not merge local and remote changes as pull > does and so it seems that F&R overwrites any local changes if there > is a conflict which requires more work and control on our side or we > may loose our work. > > Could we use Pull and then Rebase instead F&R? Don’t use “pull” and then “rebase”, this will just mess up everything. The simple rule is the following : - if you have local commits which are not yet incorporated in the origin/master branch, then do a “fetch & rebase” - otherwise, if you have no local commit, a “pull” is fine (and in that case is equivalent to a “fetch & rebase”). Houtan is going to improve the wiki page on Git, I hope this will clarify things for you. Best, -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

Fwd: RE: DSGE-net invoice
by Michel Juillard 02 Sep '10

02 Sep '10

FYI Best Michel ----- Forwarded message from giovanni.lombardo(a)ecb.int ----- Date: Wed, 1 Sep 2010 09:25:23 +0200 From: giovanni.lombardo(a)ecb.int Reply-To: giovanni.lombardo(a)ecb.int Subject: RE: DSGE-net invoice To: michel.juillard(a)ens.fr Dear Michel, thanks, I will forward it to the administration. By the way, the improvements in Dynare are impressive (and even more so those planned for 2010/2011). Well done! Best Gianni > -----Original Message----- > From: Michel Juillard [mailto:michel.juillard@ens.fr] > Sent: Tuesday 31 August 2010 21:54 > To: Lombardo, Giovanni > Subject: DSGE-net invoice > > > Dear Gianni, > > here is the invoice for DSGE-net > > All the best, > > Michel > Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. ----- End forwarded message ----- --

3 2

Compiling Dynare under Windows
by Sébastien Villemot 01 Sep '10

01 Sep '10

Hi, I have updated the wiki page about the compilation of Dynare under Windows [1]. The new procedure is simpler, and has several improvements over the previous one : — The Markov-Switching (SWZ) MEX can now be built — Under Cygwin, the preprocessor binary no longer needs Cygwin DLL in the path — Possibility of compiling MEX files for 64-bit MATLAB with GCC and the build system (previously, it was necessary to have MS Visual C++) — Possibility of cross-compiling from Linux (not documented on the wiki). Hence, the snapshot is fully rebuilt (including MEX files) every night. Also note that the snapshot is now a Windows installer, similar to the one used for stable releases. Two problems remain, which I hope to fix soon : — Dynare++ binary is currently built with vanilla BLAS and LAPACK (instead of ATLAS) — Under MATLAB 64-bit, the mexErrMsgTxt() makes MATLAB crash. This is related to C++ exception propagation, which seems to have a problem in MinGW 64-bit. Hence if you call the MEX files without arguments, you will have a MATLAB crash. But running an error-free MOD-file works fine. Please let me know if you encounter any problem with the new procedure. Best, [1] http://www.dynare.org/DynareWiki/BuildingDynareFromSource -- Sébastien Villemot CEPREMAP — http://www.cepremap.ens.fr Dynare project — http://www.dynare.org Phone: +33 1 40 77 49 90 PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)

1 0

[Trac] #118: Build system for SWZ DLL fails under Cygwin
by Trac Dynare 26 Aug '10

26 Aug '10

#118: Build system for SWZ DLL fails under Cygwin --------------------------------------+------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- The problem comes from the GSL: the package shipped with Cygwin does not link with MATLAB DLLs, which are compiled with MinGW even under Cygwin. The solution is probably to use a GSL compiled for MinGW: http://gnuwin32.sourceforge.net/packages/gsl.htm -- Ticket URL: <https://www.dynare.org/trac/ticket/118> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #96: Problem with struct2local.m
by Trac Dynare 25 Aug '10

25 Aug '10

#96: Problem with struct2local.m --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: 4.1.1 Keywords: | --------------------------+------------------------------------------------- The function struct2local.m doesn't work as expected when a function exists in the path with the same name than a variable to be unpacked. After the call to struct2local, MATLAB gives precedence to the function over the local variable. This behavior is apparently in contradiction with the precedence rules described on: http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f10-60956… However it is present on most versions of MATLAB, and should be taken as a normal behavior of MATLAB. A possible fix is to drop the use of struct2local, and to unpack structures by hand. -- Ticket URL: <https://www.dynare.org/trac/ticket/96> Dynare <http://www.dynare.org> The Dynare project

1 5

[Trac] #124: write additional documentation for 3rd order
by Trac Dynare 24 Aug '10

24 Aug '10

#124: write additional documentation for 3rd order ---------------------------+------------------------------------------------ Reporter: michel | Owner: Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ - mention use_dll in order option of stoch_simul in Reference Manual - document the output variables of 3rd order (on the Wiki?) -- Ticket URL: <https://www.dynare.org/trac/ticket/124> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #123: add external_function to the Reference Manual
by Trac Dynare 26 Jul '10

26 Jul '10

#123: add external_function to the Reference Manual ---------------------------+------------------------------------------------ Reporter: michel | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ -- Ticket URL: <https://www.dynare.org/trac/ticket/123> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] Dynare Octave problem
by George Perendia 21 Jul '10

21 Jul '10

Update FYI: After all, it seems like I can make octave debug prompt appear and work if I set dbstop (or keyboard) and then run e.g. octave> sweuromodel (i..e as..m file) instead (i.e. and after) octave> dynare sweuromodel.mod noclearall cygwin it looks like running dynare "upsets" switch to octave debug mode (i.e. same problem occur when running via dynare even if I do not use use_dll option) Best George On 21/07/2010 09:47, George Perendia wrote: > HI Sebastien > > Thanks for all your answers > > Problem is however that each described method of entering debug mode > results in my prompt and cygwin window freezing and the only thing I > can do is C-c to exit the Dynare application. I can however make the > dll print matrices to cout under octave and I can put pause and other > suitable commands in .m files to pause or control the execution so > that helps but slows down my debugging. > > Best > George > > On 20/07/2010 21:17, Sébastien Villemot wrote: >> Hi, >> >> On Mon, Jul 19, 2010 at 08:11:04PM +0100, George Perendia wrote: >>> Another issue is that when octave hits dbstop: the prompt and >>> keyboard freeze at the first line of the file dbstop is set in >>> without promptimg "debug>" mode (and not at the line I specified >>> using dbstop<fname>,<lineno>.: >> I don’t have much experience with debugging under Octave, and I don’t >> know if >> it is supposed to behave like MATLAB. I can only point you to the >> part of >> Octave manual which deals with debugging : >> >> http://www.gnu.org/software/octave/doc/interpreter/Debugging.html >> >> Best, >> > > --

1 0

[Trac] #108: Create an interface for DSGE-Var
by Trac Dynare 06 Jul '10

06 Jul '10

#108: Create an interface for DSGE-Var --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- Needs an option of estimation, which takes a value: - if the value is numeric, means that the weight of the DSGE prior is calibrated to that value - if the value is a string, means that this weight is estimated as this given parameter Also needs an option for number of lags. See: http://www.dynare.org/DynareWiki/DsgeVar -- Ticket URL: <https://www.dynare.org/trac/ticket/108> Dynare <http://www.dynare.org> The Dynare project

1 5

Re: [DynareDev] [Trac] #24: Add Markov-Switching
by Trac Dynare 01 Jul '10

01 Jul '10

#24: Add Markov-Switching ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by houtanb): Replying to [comment:1 sebastien]: > Note: the SWZ build system currently works on Linux and MacOS, but not Cygwin. The problem has to do with the GSL whichs creates conflicts with MATLAB libraries. > Ported to mex and made to work on Mac and Linux in commits between ac0f324d6fc73e281d46775c231f9bc0f21dc99e and 359b90d4fcd9a08ddc12524724b76d0fa6e202c6 -- Ticket URL: <https://www.dynare.org/trac/ticket/24#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #24: Add Markov-Switching
by Trac Dynare 01 Jul '10

01 Jul '10

#24: Add Markov-Switching ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * owner: => houtanb * status: new => accepted -- Ticket URL: <https://www.dynare.org/trac/ticket/24#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #119: Add boost/math (and possibly others) to the configure script for MEX files
by Trac Dynare 01 Jul '10

01 Jul '10

#119: Add boost/math (and possibly others) to the configure script for MEX files --------------------------------------+------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/119> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #97: estimation with mode_compute=6 fails under Octave
by Trac Dynare 25 Jun '10

25 Jun '10

#97: estimation with mode_compute=6 fails under Octave --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.1.1 Keywords: | --------------------------+------------------------------------------------- The reason is that the code uses a graphical waitbar, which is not available under Octave. The fix is to replace it by a text waitbar. See the following thread: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2531 -- Ticket URL: <https://www.dynare.org/trac/ticket/97> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #120: 1st order coefficients reported by k-order DLL are not the same than Dynare++
by Trac Dynare 25 Jun '10

25 Jun '10

#120: 1st order coefficients reported by k-order DLL are not the same than Dynare++ -------------------------+-------------------------------------------------- Reporter: sebastien | Owner: george Type: bug | Status: new Priority: critical | Milestone: Component: K-order DLL | Version: 4.1.1 Keywords: | -------------------------+-------------------------------------------------- Reproducible on a model sent by Dario Caldara. -- Ticket URL: <https://www.dynare.org/trac/ticket/120> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #107: In a MOD file, comments located on the same line than a native MATLAB instruction are not filtered out
by Trac Dynare 21 Jun '10

21 Jun '10

#107: In a MOD file, comments located on the same line than a native MATLAB instruction are not filtered out --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: 4.1.1 Keywords: | --------------------------+------------------------------------------------- At least if they are of the C form (/* */) or C++ form (//). Of course the MATLAB comments (%) will not create problems. -- Ticket URL: <https://www.dynare.org/trac/ticket/107> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #17: Update user guide
by Trac Dynare 18 Jun '10

18 Jun '10

#17: Update user guide ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: tommaso Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Documentation | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Comment(by houtanb): Replying to [comment:2 sebastien]: > Also, several .mod files referenced in the user guide no longer run correctly in Dynare. -- Ticket URL: <https://www.dynare.org/trac/ticket/17#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #5: Implement explicit writing of first order conditions of Ramsey problem
by Trac Dynare 14 Jun '10

14 Jun '10

#5: Implement explicit writing of first order conditions of Ramsey problem ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: enhancement | Status: accepted Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): A complementary feature is the creation of an intermediary MOD-file (or at least a “model” block) containing the FOC conditions of the Ramsey problem, so that the user can re-include it in a new MOD-file. In some sense, this corresponds to the use of the preprocessor as a symbolic derivation tool. -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #22: Expand specification of priors (i.e. priors on relative variances between 2 shocks)
by Trac Dynare 14 Jun '10

14 Jun '10

#22: Expand specification of priors (i.e. priors on relative variances between 2 shocks) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/22#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #17: Update user guide
by Trac Dynare 14 Jun '10

14 Jun '10

#17: Update user guide ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: tommaso Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Documentation | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Changes (by sebastien): * milestone: => 4.2 Comment: In particular, as noted by Houtan, several sections are now incorrect (in particular in the description of estimation options). This is often confusing for users, since the user guide and the reference manual give different informations. -- Ticket URL: <https://www.dynare.org/trac/ticket/17#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #25: Prototype of finite element method (ZLB)
by Trac Dynare 14 Jun '10

14 Jun '10

#25: Prototype of finite element method (ZLB) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: closed Priority: major | Milestone: 4.3 Component: Core M-files | Version: Resolution: duplicate | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: new => closed * resolution: => duplicate Comment: Duplicate of ticket #27 -- Ticket URL: <https://www.dynare.org/trac/ticket/25#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 09 Jun '10

09 Jun '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * status: reopened => accepted -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:9> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #100: Add exception for degenerate beta prior.
by Trac Dynare 09 Jun '10

09 Jun '10

#100: Add exception for degenerate beta prior. --------------------------+------------------------------------------------- Reporter: stepan | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- If the declared prior expectation and standard deviation are equal to 0.5, the prior density is not defined because in this special case the parameters \alpha and \beta are zero. We should add an exception for this case. -- Ticket URL: <https://www.dynare.org/trac/ticket/100> Dynare <http://www.dynare.org> The Dynare project

1 3

Re: [DynareDev] Estimation DLL design - prior distributions
by Stéphane Adjemian 04 Jun '10

04 Jun '10

Hi George, The inverse gamma 2 density appears naturally in Bayesian statistics when considering conjugate priors in linear Gaussian models. The inverse gamma densities are quite common in Bayesian statistics (the references you are giving are not pertinent with respect to this literature). Furthermore the inverse gamma 2 is just a re-parametrization of the probability textbook (or common if you want) inverse gamma density. This is shown in the attached pdf. So I don't think we should provide the inverse gamma prior you are suggesting in Dynare. Best, Stéphane. On 2 June 2010 10:35, George Perendia <george(a)perendia.orangehome.co.uk>wrote: > Hi Michel > > Thanks for the pdf document . > > 2) My apologies - Having had a chance to see the full representation of > both inv gamma, 1 and 2 pdf in the document you sent I do not anymore > think there is a bug in the implementation - the implementation seem to > conform closely to the given representations. > > 1) I can not tell if the notes are incorrect but they do seem mutually > consistent, so that e.g. > > lpdfig1(x,s,n) = lpdfig2(x*x,s,n) = lpdfgam(1/(x*x),n/2,2/s) - > 2*log(x*x) = 0.5673 for my test > > On the other hand, both inv gamma 1 and 2 representations differ from what > I find the most common definition of the inverse gamma from various sources > > invGammaPDF(x,a,b) = b^a / gamma(a) * 1/x ^(a+1) * exp( -b/x) which, in > turn = GammaPDF(1/x,a,1/b) / x^2 > > (though, alternative representations of gammaPDF with inverse scale beta = > 1/b would give = GammaPDF(1/x,a,beta) / x^2 ) > > (e.g. see the enclosed document or internet reference such as > http://www.chemistrydaily.com/chemistry/Inverse-gamma_distribution > or even wikipedia > http://en.wikipedia.org/wiki/Inverse-gamma_distribution ) > > We may need to add another inv Gamma for that common representation. > > Best > George > > > On 01/06/2010 20:37, Michel Juillard wrote: > > Hi George, > > inverse gamma distributions are tricky because different authors use > different notations. I attach the notes that I had made in 2004. > Could you please tell me > 1) if you think that these notes are erroneous. In this case, please, > indicate the sources that you use. > 2) if the code currently implemented in Dynare Matlab conforms with these > notes. > > I'm leaving tomorrow for the Dynare Conference. I will be back this week > end and will try to look into the issue next week. > > All the best, > > Michel > > > On 06/01/2010 09:00 PM, George Perendia wrote: > > PS: On the other hand, using the commonly used inv gamma formula > > pdgInvGamma (x,n,s) = 1/(gamma(n) * s^n) * x ^(-n-1) exp (1/ (x*s) ) > > it appear that > > pdgInvGamma (x,n,s) = pdfGamma (1/x, n, s) / x^2 > > or, in logs, > > lpdfinvg (x,n,s) = -gammaln(n) - n*log(s) + (n+1)*log(1/x) - (1/x)/s > = [ -gammaln(n) - n*log(s) + (n-1)*log(1/x) - (1/x)/s ] - 2*log(x) = [ > lpdfgam(1/x,n,s) ] - 2*log(x) > > Best regards > > George > > On 01/06/2010 16:24, George Perendia wrote: > > Dear Michel > > thanks > > I have 2 issues: > > 1) According to few sources, > If x~InvGamma(a,b) , then 1/x ~Gamma(a,1/b) distribution > however, in our dynare inv gamma 2 (lpdfig2.m) we have different > definition: > X ~ IG2(s,nu) if X = inv(Z) where Z ~ G(nu/2,2/s) (Gamma distribution) > (which is equivalent to > If x~InvGamma(a,b) , then 1/x ~Gamma(b/2,2/a) distribution) > > 2) I suspect there are a bugs in implementation for both invg2 and invg1 > even as per our specifications of invg2 aind invg1, i.e. > for invg2: we have > > ldens(idx) = -gammaln(.5*nu) - (.5*nu)*(log(2)-log(s)) - > .5*(nu+2)*log(x(idx)) -.5*s./x(idx); > > and for e.g. s=2, n=5 and x= 0.5 as a result we have (incorrectly?): > > lpdfig2(x,s,n) = > -gammaln(.5*n) - (.5*n)*(log(2)-log(s)) - .5*(n+2)*log(x) -.5*s./x > > ans = > > 0.1413 > > whilst > > lpdfgam(1/x,n/2,2/s) > > ans = > > -1.2450 > > and modified (corrected?) invgam2 with ...(nu - 2).which meets our spec.. > instead of (nu + 2)... > > K>> -gammaln(.5*n) - (.5*n)*(log(2)-log(s)) - .5*(n-2)*log(x) -.5*s./x > > ans = > > -1.2450 > > thus, gives same result as lpdfgam(1/x,n/2,2/s). > > > Similarly, invg1 > > ldens(idx) = log(2) - gammaln(.5*nu) - .5*nu*(log(2)-log(s)) - > (nu+1)*log(x(idx)) - .5*s./(x(idx).*x(idx)) ; > > lpdfig1(x,s,n)= 0.5673 = > lpdfig2(x*x,s,n)= 0.5673 > > whilst > lpdfgam(1/(x*x),n/2,2/s) > > ans = > > -2.2052 > > and modified invg1 without leading log(2) and with nu-2 instead nu+1 > > - gammaln(.5*nu) - .5*nu*(log(2)-log(s)) - (nu-2)*log(x) - .5*s./(x.*x) > > ans = > > -2.2052 > > i.e. = lpdfgam(1/(x*x),n/2,2/s) > as per definition > > (... though I may have got something wrong) > > > If they are bugs, shall I log them and correct them? > > Best > george > > On 19/05/2010 20:29, Michel Juillard wrote: > > Dear George, > > thank you for the message. I agree that we should go with BOOST. > > 1) In the estimation DLL, we only need a uniform and a normal random > generator and the pdfs for the normal, beta, gamma, inverse gamma 1, inverse > gamma 2 and the uniform. You shouldn't try to implement more than that at > this stage. > > 2) for the inverse gamma 1 and 2 pdfs, you can directly translate the > current matlab function in ./matlab/distributions. We should add the source > of the algorithm if we can remember. > > 3) You need to look at the Matlab implementation, because we need the same > kind of generalizations: > - gamma is defined as greater than p3 rather than greater than 0 > - beta is defined over [p3; p4] instead of over [0,1] > > The relevant Matlab functions are set_prior.m and priordens.m > > All the best, > > Michel > > > > > On 05/19/2010 06:42 PM, George Perendia wrote: > > Hi Sebastien > > I started looking into priordens and pdfs as well as the relvant random > number generators (rng-s) for estimated parameters (*) and investigated two > options: C gsl and the C++ header BOOST as initially suggested by Stephane. > > Both provide for the most of the requirements but there are seeral > insufficiencies. > > gsl provides the necessary pair of pdf and random number generators > functions based on given uniform random number but not the uniform random > number generator - rng (or the pdf but that is trivial to add). > > On the other hand whilst BOOST provides a large variety of functions > including the pdfs and cdfs in a template form as well as a variety of > uniform and other distributions rngs and ways to combine them. Though it > does not seem to provide a rng for beta, the beta rng may be easily derived > using gamma rng and, e.g. the relation: > > "If *X* and *Y* are independently distributed Gamma<http://wiki/Gamma_distribution> > (*α*, *θ*) and Gamma(*β*, *θ*) respectively, then *X* / (*X* + *Y*) is > distributed Beta(*α*, *β*), " > > ...which is how gsl beta rng is implemented anyway: > > Neither gsl nor Boost however seem to provide pdfs or rngs for > inverse_gamma and that would need to be derived for either of them too. > > Whilst the gsl is simpler it is C whlst the BOOST is C++. Also, gsl would > require a library compilation before it can be used and it would also be an > additional package requirement for building Dynare (i.e. whilst we are > already using BOOST header library anyway). > > It seems that BOOST pdfs and rngs are better documented, provide a larger > variety of options for later extensions and fit better into our design > strategy whilst, as part of already used BOOST, they do not require any > extension on the overall maintenance and build requirements of Dynare. > > I wold be inclined therefore to suggest us to use BOOST but please do let > me know if you have any objections or other suggestions. > > If the performance is the issue, we can run a comparative test e.g. for > throwing 100000 beta rng-s and deriving their pdf-s.using gsl and BOOSt and > see the difference but that may a be bit excessive - just use of a different > uniform rng for generating specific distribution rng from a variety of those > available in BOOST can change performance dramatically. > > *) assuming the following distributions are required > beta_pdf | gamma_pdf | normal_pdf | uniform_pdf | inv_gamma_pdf | > inv_gamma1_pdf | inv_gamma2_pdf > > Best regards > George > > > On 18/05/2010 17:26, Sébastien Villemot wrote: > > Hi George, > > On Wed, May 12, 2010 at 09:36:26AM +0100, George Perendia wrote: > > > It was good to work together last week. > Aftert yesterday's ACES meeting it looks like I may not be engaged > full time on ACES for now, so, I could contiue on Estimation DLL, > 1-2 days a week for time being, e.g. on prior dens, optmiiser > integration, MCMC or something else. > Let me know what wold be best for you. > > > Sorry for my late answer. > > I am also happy with the progress that we made when you came to Paris. > > Unfortunately, since I have been working on other projects, I have not been able to finalize the likelihood DLL yet, but I am quite close to it. > > I am leaving for vacations until May 30, and I hope to finish the DLL by the first days of June. Note that I will still read and answer to emails during my vacations. > > Please feel free to advance on the implementation of other parts of the design. In particular, we need to decide how to implement the prior densities. We should rely on existing code rather than reimplementing all the probability density functions. My feeling is that using the GNU Scientific Library for that purpose is the easiest way, since all the PDFs are there and it is licensed under the GPL. Do you have any other option in mind ? > > Best, > > > > > > -- > > > > > > > > > > -- > > > > > > > -- > > > > > > > > > > -- > > Best regards > George > 07951415480 > > > > > -- Stéphane Adjemian CEPREMAP & Université du Maine Tel: (33)1-43-13-62-39

2 3

Re: [DynareDev] [Trac] #24: Add Markov-Switching
by Trac Dynare 01 Jun '10

01 Jun '10

#24: Add Markov-Switching ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): Note: the SWZ build system currently works on Linux and MacOS, but not Cygwin. The problem has to do with the GSL whichs creates conflicts with MATLAB libraries. -- Ticket URL: <https://www.dynare.org/trac/ticket/24#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #104: Add option pruning
by Trac Dynare 31 May '10

31 May '10

#104: Add option pruning --------------------------+------------------------------------------------- Reporter: stepan | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Add option pruning in stoch_simul for second order simulations. The preprocessor should set options_.pruning equal to one if pruning option is used. The preprocessor should issue a warning if pruning and k_order_solver are used simultaneously (pruning is not available in dynare_simul_). -- Ticket URL: <https://www.dynare.org/trac/ticket/104> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #14: Create a database of old and new example MOD files
by Trac Dynare 30 Apr '10

30 Apr '10

#14: Create a database of old and new example MOD files ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Documentation | Version: Resolution: | Keywords: ----------------------------+----------------------------------------------- Comment(by sebastien): Database started in commit 4a619f3db74b95aaca5c2a16a990d619df9975c4 -- Ticket URL: <https://www.dynare.org/trac/ticket/14#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #46: Update examples on the website
by Trac Dynare 28 Apr '10

28 Apr '10

#46: Update examples on the website ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ Most MOD files examples distributed on the website don't work with Dynare 4. They were designed for Dynare 3. We regularly get posts on the forum by newcomers to Dynare who don't understand why these examples fail. We should update them to Dynare 4. -- Ticket URL: <https://www.dynare.org/trac/ticket/46> Dynare <http://www.dynare.org> The Dynare project

1 1

Estimation Parameters design
by George Perendia 28 Apr '10

28 Apr '10

Hi Sebastien (et al) On our EstimationModule design wiki page http://www.dynare.org/DynareWiki/EstimationModule we have few _id vectors indexing shocks and measurement errors correlation parameters into xparam1 such as.. * ncx_id ncx by 1 vector of integers.(for estimated structural shock correlations). . * ncn_id ncn by 1 vector of integers (estimated measurement error correlations). We have those *_id's indices into xparam1 but what indices are there into Q and H matrices respectively , including for pairs of (symmetric) coordinates on the lines of estim_params_.corrx(i,1); and k1 = options_.lgyidx2varobs(estim_params_.corrn(i,1)); *used in DsgeLikelihood.m*? Shall we continue to use those as separate entities in estim_params_, including. estim_params_.var_exo and estim_params_.var_endo, or store separate new ones into the new EstimationModule params structure? -- Best regards George

2 4

New Dynare branches
by Sébastien Villemot 22 Apr '10

22 Apr '10

Hi everyone, I have recently created two new branches on the Dynare repository: * "gpm": a branch for keeping the current Dynare version used for the GPM (Global Projection Models) project * "dr1break": a topic branch to redesign dr1.m along the lines of: http://www.dynare.org/DynareWiki/BreakingDr1 This branch will be merged back in master when the job is finished. Unless you're explicitly involved in one of these two projects, you can safely ignore these branches. Best -- Sébastien Villemot

1 0

Kalman Filter accuracy
by George Perendia 21 Apr '10

21 Apr '10

Hi there I am implementing Kalman Filter in C++ There however appear that some apparently minor numerical discrepancies between Matlab and C++ versions of T and R matrices (i.e. the ghx and ghu matrices, and probably the other calculations too), are gradually creeping-up to a rather significan difference in the KF log-likelihood calculation and I am trying to figure out what can be done about it. The main impact seem to be on the inv(F) due to rather low values appearing in F. where F=ZPZ'+H resulting in a significant impact on the log likelihood and, as well, the next step P and system state forecast since both depend on the gain matrix K=P*Z' *invF and thus on invF; I.e. C++ F: F.data[0] = 0.00037206242498542022 F.data[1] =[2] = -0.00045917810077178716 F.data[3] = 0.0008672061055033099 and (rounded up) inverse of C++ F invF = [7756 4106.76; 4106.76 3327.6] (or using Matlab for inversion calculation invF = 1.0e+003 * 7.7560 4.1068 4.1068 3.3276) whilst Matlab Dynare F = 1.0e-003 * 0.3370 -0.4437 -0.4437 0.8383 and its iF = inv(F) = 1.0e+003 * 9.7907 5.1823 5.1823 3.9360 Then, e.g. Matlab likelihood factor v'*iF*v = 963.6491 whilst the C++ one is 771.88779, thus, discrepancies pretty much affecting the total LL calculation to say the least. It may also be a question which one is the more correct result. Any suggestions? PS: both, C++ and Matlab Dynare use the same C++<model>_dynamic.dll to calculate the initial jacobian but the jacobians differ. Best regards, George

2 2

[Trac] #92: Add erf() and normpdf() as primitives
by Trac Dynare 16 Apr '10

16 Apr '10

#92: Add erf() and normpdf() as primitives --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/92> Dynare <http://www.dynare.org> The Dynare project

1 3

Kalman Filters conversion
by George Perendia 16 Apr '10

16 Apr '10

Hi 1) In the present Matlab kalman_filter.m suite, the steady state conversion is checked as notsteady = max(max(abs(K-oldK))) > riccati_tol; where K = P(:,mf)*inv(F); is the gain matrix and the first Kold=0; One problem with that is that, however unlikely, the first K may be sufficiently small, close to 0, leading to a wrong inference that the conversion to steady state occurred in the first step. To avoid that (unlikely) situation, Kold may be set to Inf or some other very large value instead or, the check should take place only if t>1, though setting the first Kold=Inf is a more straight forward change in Matlab kalman_filter.m. 2) Though Harvey (1989) and some other authors assumes convergence when the whole P matrix converges (and the whole P convergence was checked in the initial C++ Kalmn Filte implementations) I wander if we should implement the above gain matrix convergence as a sufficient criteria in the new C++ KalmnFilter instead. If so, I can make checks work for t>0 only. -- Best regards George

2 3

problem with struct2local
by Michel Juillard 14 Apr '10

14 Apr '10

Hi there, struct2local.m is a function that make local variables out of the fields of a structure. This function creates a problem in some circumstances (details below) at least with Matlab R2010a. I had replaced it in a previous commit, but I should have sent a message to this list rather than relay only on the commit message in GIT. As illustrated with the 2 functions attached, if one of the fieldname is also the name of a function present in the path, an 'if' statement calls the function instead of the local variable. This is in contradiction with the priorities for searching symbol names stated by Matlab documentation and it looks like a Matlab bug, maybe it affects only R2010a, but I didn't get a chance to try with other Matlab versions. In any case, we can't use struct2local and it is safer to unroll the fieldnames by hand. In addition, we may create only the local variables actually needed by the function rather than all the fields of the structure. All the best, Michel -------- Original Message -------- Subject: Re: commits Date: Fri, 09 Apr 2010 11:38:51 +0200 From: Sébastien Villemot <sebastien.villemot(a)ens.fr> To: Marco Ratto <marco.ratto(a)jrc.ec.europa.eu> CC: Stéphane Adjemian <stephane.adjemian(a)gmail.com>, Michel Juillard <michel.juillard(a)ens.fr> References: <4BBDF623.3060701(a)jrc.ec.europa.eu> Hi Marco, Le jeudi 08 avril 2010 à 17:28 +0200, Marco Ratto a écrit : > I did a number of commits related to parallel dynare. Thanks for that. I have a problem with your commit 320266412... dated 08 april 2010 17:15:15: it reverts to the use of struct2local(), which was removed by Michel in his commit 2679e190e8... dated 02 april 2010 21:37:43. It seems that Michel had problems with struct2local() on MATLAB R2010a, so he purposedly removed the use of that function. I guess Michel and you have to find an agreement on what is the best solution there. -- Sébastien Villemot

3 7

Proposal for simplification in dr1.m and implementation of stoch_simul and estimation with a block decomposed model
by fmihoubi＠univ-evry.fr 10 Apr '10

10 Apr '10

Hi everyone, In order to implement the check command, stochastic simulation and estimation with a block decomposed model, I have to modify the dr1.m file at least to include a loop on each block. I have the feeling that it will be time saving (especially during the estimation) to reduce the amount of work done in dr1.m and set_state_space.m files and to do it once for all during the preprocessing step. For example: - The Jacobian matrix could be reordered during the preprocessing step. The variables are already reordered in the block decomposition, so for each block the variables could be reordered one more time (first the pure static variables, second the predetermined variables, third both forward and backward variables and fourth the purely forward variables). - The model reduction step could be done using the computation of feedback variables instead of a QR decomposition in dr1. The block should be correctly reduced as soon only static variables could belong to the recursive part of the block. - Since the endogenous variables with more than one lag or one lead are replaced with intermediate variables, the lead_lag_incidence matrix could be considered as a matrix with three rows and the way to build the E and D matrices could be simplified. In addition those matrices could be computed only for blocks containing both lead and lag endogenous variables and they could be defined once for all during the preprocessing step, and simply evaluated during the estimation. The estimation step could be carried on with the C++ implementation of Dsge Likelihood using the DLL-file bytecode to evaluate the block decomposed model. Best, Ferhat ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 1

Release of 4.1.1
by Sébastien Villemot 06 Apr '10

06 Apr '10

Hi, I just released Dynare 4.1.1. This is a bugfix release. The new source tarball, the Windows package, and the updated reference manual have been put on the website. I will wait until the Mac package is ready before making the official announcement. Best -- Sébastien Villemot

1 0

Re: [DynareDev] [Trac] #80: Crashes of Dynare++ under Windows
by Trac Dynare 06 Apr '10

06 Apr '10

#80: Crashes of Dynare++ under Windows ------------------------+--------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: Dynare++ | Version: 4.1.0 Resolution: fixed | Keywords: ------------------------+--------------------------------------------------- Changes (by sebastien): * status: new => closed * resolution: => fixed Comment: The official MinGW of GCC 4.4 (which uses Dwarf-2) also has the bug. So the only solution for the GCC 4.4 series is to use SJLJ unwinding, which is provided by TDM build. Issue fixed in Windows package of Dynare 4.1.1. -- Ticket URL: <https://www.dynare.org/trac/ticket/80#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #88: smoother is computed for auxiliary variables
by Trac Dynare 06 Apr '10

06 Apr '10

#88: smoother is computed for auxiliary variables --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The smoother is currently computed for all variables, including auxiliary variables. The smoother should be computed only for requested variables -- Ticket URL: <https://www.dynare.org/trac/ticket/88> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 06 Apr '10

06 Apr '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: reopened Priority: minor | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * priority: major => minor * status: closed => reopened * resolution: fixed => Comment: External functions need to be implemented with USE_DLL and bytecode. -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:8> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #91: Univariate smoother with missing observations needs corrections.
by Trac Dynare 03 Apr '10

03 Apr '10

#91: Univariate smoother with missing observations needs corrections. --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The last block (if nargout>7) is wrong and cause dynare to crash. Variable iF is not defined in this function (should be Fi i think). There is also a problem with the selection matrix Z. -- Ticket URL: <https://www.dynare.org/trac/ticket/91> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #74: Variance decomposition gives dummy results in the presence of non-stationary vars
by Trac Dynare 03 Apr '10

03 Apr '10

#74: Variance decomposition gives dummy results in the presence of non- stationary vars --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- In the attached MOD file, the variance decomposition is clearly bogus: some lines don't sum to 100% (some percentages are even negative). The problem does not occur with Dynare 4.0.4. This is probably related to the fact that this model contains a non-stationary variable. The file {{{th_autocovariances.m}}} has changed between versions 4.0.4 and 4.1.0 with respect to the treatment of stationary variables. Also note that the problem does not come from the fact that some shocks are switched off (with a zero variance) in the attached MOD file. Activating all the shocks still gives dummy results. -- Ticket URL: <https://www.dynare.org/trac/ticket/74> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Trac] #21: Add partial information
by Trac Dynare 24 Mar '10

24 Mar '10

#21: Add partial information ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: george Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: => 4.2 Comment: As of 2010-03-24, part of the work has been done. Two minor issues to be solved (among others): * the file matlab/disclyap_fast.m has no copyright: this should be clarified * the files matlab/partial_information/{qzswitch,qzdiv}.m are redundant with the versions in matlab/qz. These files should be deleted once the PI code relies on mjdgges. -- Ticket URL: <https://www.dynare.org/trac/ticket/21#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

options_.partial_information
by George Perendia 19 Mar '10

19 Mar '10

Hi Michel and Sebastien (et al) The partial information is now failing in estimation_1.m (on line 1096) since there is no PI Kalman smother available yet. As an interim solution we suggest to bypass that whole if ... diagnostics block by adding an additional clause & options_.partial_information == 0 to its if test on lines 1086-1088 , i.e. if (~((any(bayestopt_.pshape > 0) & options_.mh_replic) | (any(bayestopt_.pshape ... > 0) & options_.load_mh_file)) ... | ~options_.smoother ) & M_.endo_nbr^2*gend < 1e7 ... & options_.partial_information == 0 % to be fixed . Would that be ok? -- Best regards George

2 1

[Trac] #82: prior_analysis and posterior_analysis commands broken
by Trac Dynare 18 Mar '10

18 Mar '10

#82: prior_analysis and posterior_analysis commands broken --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The prior_analysis and posterior_analysis commands are broken: the calling sequence generated by the preprocessor doesn't match the calling sequence of the MATLAB function... Their documentation in the ref. manual also needs updating. -- Ticket URL: <https://www.dynare.org/trac/ticket/82> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #65: Second derivatives w.r.t. parameters
by Trac Dynare 15 Mar '10

15 Mar '10

#65: Second derivatives w.r.t. parameters --------------------------+------------------------------------------------- Reporter: ratto | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: 4.2-alpha2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- In identification analysis, for the computation of the Jacobian of typical optimization problems like moment matching (limited information). -- Ticket URL: <https://www.dynare.org/trac/ticket/65> Dynare <http://www.dynare.org> The Dynare project

1 5

Re: [DynareDev] [Trac] #19: Add tool to automatically write a stationary version of the model, given trends supplied by user
by Trac Dynare 12 Mar '10

12 Mar '10

#19: Add tool to automatically write a stationary version of the model, given trends supplied by user ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by houtanb): * owner: sebastien => houtanb * status: new => accepted -- Ticket URL: <https://www.dynare.org/trac/ticket/19#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] Estimation DLL design
by George Perendia 12 Mar '10

12 Mar '10

Hi If nspred is number of predetermined variables in the state vector defined in set_state_space.m as dr.nspred = sum(kstate(:,2) <= M_.maximum_endo_lag+1); Can nspred then be larger than npred, i.e. the total number of predetermined variables (=nboth + only predetermined)? , i.e.in dynare_estimation_1.m we have: bayestopt_.restrict_columns = [ic; length(k2)+(1:nspred-npred)']; but the differnce ia then not supposed to be larger than 0 and the second term in the square brackets should then never yield anything other than zero length vector so it appears redundant - or am I missing something. -- Best regards George

1 0

[Trac] #32: Report MATLAB crashes on Linux/64 to Mathworks
by Trac Dynare 10 Mar '10

10 Mar '10

#32: Report MATLAB crashes on Linux/64 to Mathworks --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- On Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX). See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB. The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64. As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on. We need to report this to Mathworks. -- Ticket URL: <https://www.dynare.org/trac/ticket/32> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #60: Fix memory leaks in k_order_perturbation DLL
by Trac Dynare 09 Mar '10

09 Mar '10

#60: Fix memory leaks in k_order_perturbation DLL -------------------------+-------------------------------------------------- Reporter: sebastien | Owner: george Type: bug | Status: new Priority: minor | Milestone: Component: K-order DLL | Version: Keywords: | -------------------------+-------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/60> Dynare <http://www.dynare.org> The Dynare project

1 6

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 09 Mar '10

09 Mar '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: closed Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: assigned => closed * resolution: => fixed Comment: Maximum sharing implemented in 4f6a3669c6b86375a31adedc3338db33aa973836 Temporary terms implemented in 30ea396a08adcad6ea3ca42082611b3e977f3e51 Documentation in ref. manual in 9451c56d3d26fc90267ba07ea3c7528eaba25bd8 -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:7> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model
by Trac Dynare 23 Feb '10

23 Feb '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: assigned Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): First version of this feature implemented in commit 12c4a52ebc5e95af537a7b7163bde2d34de2e46f. Still need to add: * inside DataTree, a table for maximum sharing between nodes associated to external functions * computation of temporary terms, in particular a way to optimize calls to jacobian and hessian functions -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:6> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #84: normcdf() doesn't work with k_order
by Trac Dynare 23 Feb '10

23 Feb '10

#84: normcdf() doesn't work with k_order --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The reason is that normcdf() is not translated into C code. It can easily be fixed using the erf() function available from the math library. -- Ticket URL: <https://www.dynare.org/trac/ticket/84> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #89: Add bsxfun function for old versions of matlab.
by Trac Dynare 23 Feb '10

23 Feb '10

#89: Add bsxfun function for old versions of matlab. --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Built in function bsxfun appeared in matlab version 7.4. Dynare (with matlab's version < 7.4) may crash (depending on what the user is doing) because this function is missing. We have first to add an m file (in the missing subdirectory) doing the same job as bsxfun. This workaround will be at the cost of computing efficiency (built in bsxfun is very fast). So, if we really want to be compatible with all the versions of matlab since 7.0 (or 6.5.1 I can't remember) we have to write a mex file (it should be possible to use the source of the octave's built-in). -- Ticket URL: <https://www.dynare.org/trac/ticket/89> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #62: error message from histval syntax
by Trac Dynare 23 Feb '10

23 Feb '10

#62: error message from histval syntax --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- if one writes wrongly histval; y = 1; end; instead of histval; y(0)=1; end; there is no error message with the line number where the error occurs Note also that the reference manual is missleading because the (lag) doesn't appear in the syntax -- Ticket URL: <https://www.dynare.org/trac/ticket/62> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #90: Inconsistency between Brooks & Gelman convergence diagnostics and mh_drop
by Trac Dynare 18 Feb '10

18 Feb '10

#90: Inconsistency between Brooks & Gelman convergence diagnostics and mh_drop --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: new Priority: trivial | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Brooks & Gelman convergence diagnostics are not always consistent with the way the posterior moments are computed. These diagnostics are built discarding half of the simulations at each step. By default the posterior moments are computed discarding half of the mcmc draws... But if the user changes the value of mh_drop, 100*mh_drop percent of the mcmc draws will be discarded when computing posterior moments, while the convergence diagnostics still discard the first half of the simulation at each step. The fix is to replace .5 by options_.mh_drop in McMCDiagnostics_core.m -- Ticket URL: <https://www.dynare.org/trac/ticket/90> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #81: bicgstab function does not exist in Octave 3.0
by Trac Dynare 17 Feb '10

17 Feb '10

#81: bicgstab function does not exist in Octave 3.0 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- bicgstab function exists in both MATLAB and Octave 3.2, but not in Octave 3.0. This break option stack_solve_algo=3 under Octave 3.0. The fix is probably to backport the function from Octave 3.2 to Octave 3.0, and add in the matlab/missing/ subdir. -- Ticket URL: <https://www.dynare.org/trac/ticket/81> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #76: Under Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "msvc" option
by Trac Dynare 17 Feb '10

17 Feb '10

#76: Under Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "msvc" option --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The fix is easy: in ModFile.cc, use MATLAB's error() command instead of exiting the preprocessor when neither "cygwin" nor "msvc" is specified under MATLAB/Windows. -- Ticket URL: <https://www.dynare.org/trac/ticket/76> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #80: Crashes of Dynare++ under Windows
by Trac Dynare 17 Feb '10

17 Feb '10

#80: Crashes of Dynare++ under Windows ------------------------+--------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Dynare++ | Version: 4.1.0 Resolution: | Keywords: ------------------------+--------------------------------------------------- Comment(by sebastien): Also note that MinGW GCC 4.4.1 with Dwarf-2 exceptions (from TDM) also creates the problem. But GCC 4.3.0 with Dwarf-2 exceptions (bundled with Octave/MinGW 3.2.2) does not create the problem. So the issue is specific to Dwarf-2 in 4.4 series. -- Ticket URL: <https://www.dynare.org/trac/ticket/80#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #80: Crashes of Dynare++ under Windows
by Trac Dynare 17 Feb '10

17 Feb '10

#80: Crashes of Dynare++ under Windows ------------------------+--------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Dynare++ | Version: 4.1.0 Resolution: | Keywords: ------------------------+--------------------------------------------------- Comment(by sebastien): This is a compiler issue. When compiled with MinGW GCC 4.4.0 with Dwarf-2 exceptions (bundled with Octave/MinGW 3.2.3), the problem occurs. When compiled with MinGW GCC 4.4.1 with Sjlj exceptions (from TDM - http://www.tdragon.net/recentgcc/ ), the problem does not occur. This should be taken into account when producing Dynare++ in the next Dynare release. Note: For installing TDM GCC, use the bundled installer (check gfortran, uncheck add to the PATH), this will install MinGW in c:\MinGW\. Then run the two commands for compilation (from Octave's MSYS): {{{ export PATH=$PATH:/c/MinGW/bin:/c/Octave/3.2.3_gcc4.4.0/bin ./configure CPPFLAGS="-I/home/user/boost_1_41_0" LDFLAGS="-L/c/Octave/3.2.3_gcc4.4.0/lib" --disable-octave }}} The MinGW with Dwarf-2 exceptions is probably only mandatory for Octave MEX files (this needs to be checked). -- Ticket URL: <https://www.dynare.org/trac/ticket/80#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

bsxfun
by George Perendia 17 Feb '10

17 Feb '10

Hi Running fs2000k2a.mod I encountered an error ??? Undefined command/function 'bsxfun'. Error in ==> disp_moments at 48 y = bsxfun(@minus, y, m); any ideas why bsxfun is missing or what was intended? -- Best regards George 07951415480

4 4

options_.diffuse_d
by Michel Juillard 15 Feb '10

15 Feb '10

When we implemented the diffuse filter/smoother, we used options_.diffuse_d to record the number of iterations spent in the diffuse part of the filter. 1) in the filter functions in kalman/likelihood, it is not used anymore except in univariate_diffuse_kalman_filter_corr.m. It is still present in the old (and not yet replaced) smoother functions. 2) in the multivariate case, diffuse_d can be interpreted as the number of periods for which we use the diffuse step. In the univariate case, diffuse_d is incremented inside the variable loop and can't be interpreted this way 3) when there is no missing observations, the number of period iterations spent in the diffuse step is equal to the highest order of integration of the variables of the model. The field name in oo_.smoother reflect this. But hen missing observations are present, its interpretation is much less clear. 4) In the past, we wanted to monitor diffuse_d, to make sure that it didn't change because of numerical issues. Now that we are using the Schur transformation of the transition equation, the numerical instability seems to have disappeared. All that to say that my inclination would be for dropping oo_.diffuse_d entirely. What do you think? Ondra, I know that this will create problems for GPM and its current infrastructure code. But I think that we should handle this problem in a different way, taking into account the number of periods with missing observations at the beginning of the sample and the order of intergation of the GPM model (== 1) that we know by construction. All the best, Michel

2 1

Re: [DynareDev] options_.diffuse_d
by ondra.kamenik＠gmail.com 14 Feb '10

14 Feb '10

I agree. Ondra K. ------Original Message------ From: Michel Juillard To: List for Dynare developers To: Ondra Kamenik To: Benes, Jaromir Sent: Feb 14, 2010 14:21 Subject: options_.diffuse_d When we implemented the diffuse filter/smoother, we used options_.diffuse_d to record the number of iterations spent in the diffuse part of the filter. 1) in the filter functions in kalman/likelihood, it is not used anymore except in univariate_diffuse_kalman_filter_corr.m. It is still present in the old (and not yet replaced) smoother functions. 2) in the multivariate case, diffuse_d can be interpreted as the number of periods for which we use the diffuse step. In the univariate case, diffuse_d is incremented inside the variable loop and can't be interpreted this way 3) when there is no missing observations, the number of period iterations spent in the diffuse step is equal to the highest order of integration of the variables of the model. The field name in oo_.smoother reflect this. But hen missing observations are present, its interpretation is much less clear. 4) In the past, we wanted to monitor diffuse_d, to make sure that it didn't change because of numerical issues. Now that we are using the Schur transformation of the transition equation, the numerical instability seems to have disappeared. All that to say that my inclination would be for dropping oo_.diffuse_d entirely. What do you think? Ondra, I know that this will create problems for GPM and its current infrastructure code. But I think that we should handle this problem in a different way, taking into account the number of periods with missing observations at the beginning of the sample and the order of intergation of the GPM model (== 1) that we know by construction. All the best, Michel Sent from my BlackBerry® wireless device

1 0

Re: [DynareDev] [Dynare Git] Dynare branch, master, updated. a83c0e68c70df4481ab269a1de493eabb804df71
by Michel Juillard 12 Feb '10

12 Feb '10

I wonder whether ierating the product of the transition matrix in forecast is not less accurate than taking the power of the matrix. But I agree that it must be faster for large matrices. Maybe we should decompose the matrix before the loop and only take the power of the eigenvalues. Best Michel Stephane Adjemian wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "Dynare". > > The branch, master has been updated > via a83c0e68c70df4481ab269a1de493eabb804df71 (commit) > from a828c3d2c1edf1bc4465561a425a9591910c0dc3 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit a83c0e68c70df4481ab269a1de493eabb804df71 > Author: Stéphane Adjemian (Charybdis) <stephane.adjemian(a)ens.fr> > Date: Fri Feb 12 12:31:32 2010 +0100 > > Bug fix and efficiency changes in smoothing routines. > > diff --git a/matlab/DiffuseKalmanSmoother1.m b/matlab/DiffuseKalmanSmoother1.m > index 8e624ad..ef64185 100644 > --- a/matlab/DiffuseKalmanSmoother1.m > +++ b/matlab/DiffuseKalmanSmoother1.m > @@ -59,7 +59,7 @@ spstar = size(Pstar1); > v = zeros(pp,smpl); > a = zeros(mm,smpl+1); > atilde = zeros(mm,smpl); > -aK = zeros(nk,mm,smpl+1); > +aK = zeros(nk,mm,smpl+nk); > iF = zeros(pp,pp,smpl); > Fstar = zeros(pp,pp,smpl); > iFinf = zeros(pp,pp,smpl); > @@ -71,11 +71,11 @@ P = zeros(mm,mm,smpl+1); > Pstar = zeros(spstar(1),spstar(2),smpl+1); Pstar(:,:,1) = Pstar1; > Pinf = zeros(spinf(1),spinf(2),smpl+1); Pinf(:,:,1) = Pinf1; > crit = options_.kalman_tol; > -crit1 = 1.e-8; > +crit1 = 1.e-8; > steady = smpl; > rr = size(Q,1); > QQ = R*Q*transpose(R); > -QRt = Q*transpose(R); > +QRt = Q*transpose(R); > alphahat = zeros(mm,smpl); > etahat = zeros(rr,smpl); > r = zeros(mm,smpl+1); > @@ -99,7 +99,7 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > a(:,t+1) = T*atilde(:,t); > aK(1,:,t+1) = a(:,t+1); > for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Linf(:,:,t) = T - Kinf(:,:,t)*Z; > Fstar(:,:,t) = Pstar(mf,mf,t); > @@ -129,9 +129,9 @@ while notsteady & t<smpl > K(:,:,t) = T*PZI; > L(:,:,t) = T-K(:,:,t)*Z; > a(:,t+1) = T*atilde(:,t); > - aK(1,:,t+1) = a(:,t+1); > + aK(1,:,t+1) = a(:,t+1); > for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T)-T*P(:,mf,t)*transpose(K(:,:,t)) + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -154,7 +154,7 @@ while t<smpl > a(:,t+1) = T*a(:,t) + K_s*v(:,t); > aK(1,:,t+1) = a(:,t+1); > for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > t = smpl+1; > @@ -174,4 +174,4 @@ if d > alphahat(:,t) = a(:,t) + Pstar(:,:,t)*r0(:,t) + Pinf(:,:,t)*r1(:,t); > etahat(:,t) = QRt*r0(:,t); > end > -end > +end > \ No newline at end of file > diff --git a/matlab/DiffuseKalmanSmoother1_Z.m b/matlab/DiffuseKalmanSmoother1_Z.m > index f5614af..debf47c 100644 > --- a/matlab/DiffuseKalmanSmoother1_Z.m > +++ b/matlab/DiffuseKalmanSmoother1_Z.m > @@ -105,8 +105,8 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > a(:,t+1) = T*atilde(:,t); > aK(1,:,t+1) = a(:,t+1); > % isn't a meaningless as long as we are in the diffuse part? MJ > - for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Linf(:,:,t) = T - Kinf(:,:,t)*Z; > Fstar(:,:,t) = Z*Pstar(:,:,t)*Z'; > @@ -138,10 +138,13 @@ while notsteady & t<smpl > L(:,:,t) = T-K(:,:,t)*Z; > a(:,t+1) = T*atilde(:,t); > Pf = P(:,:,t); > + aK(1,:,t+1) = a(:,t+1); > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*atilde(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*T'-T*P(:,:,t)*Z'*K(:,:,t)' + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -162,10 +165,13 @@ while t<smpl > atilde(:,t) = a(:,t) + PZI*v(:,t); > a(:,t+1) = T*atilde(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*atilde(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > end > t = smpl+1; > diff --git a/matlab/DiffuseKalmanSmoother3.m b/matlab/DiffuseKalmanSmoother3.m > index 1127cf6..514890c 100644 > --- a/matlab/DiffuseKalmanSmoother3.m > +++ b/matlab/DiffuseKalmanSmoother3.m > @@ -165,13 +165,14 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+transpose(tril(Pstar(:,:,t),-1)); > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*transpose(T)+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*transpose(T); > - P0=Pinf(:,:,t+1); > + P0 = Pinf(:,:,t+1); > if newRank, > %newRank = any(diag(P0(mf,mf))>crit); > newRank = rank(P0,crit1); > @@ -207,12 +208,15 @@ while notsteady & t<smpl > P(:,:,t)=tril(P(:,:,t))+transpose(tril(P(:,:,t),-1)); > end > end > - a1(:,t+1) = T*a(:,t); > + a1(:,t+1) = T*a(:,t); > Pf = P(:,:,t); > + aK(1,:,t+1) = a1(:,t+1); > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T) + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -239,10 +243,13 @@ while t<smpl > end > a1(:,t+1) = T*a(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > end > ri=zeros(mm,1); > diff --git a/matlab/DiffuseKalmanSmoother3_Z.m b/matlab/DiffuseKalmanSmoother3_Z.m > index b30e3b3..c6fa2a2 100644 > --- a/matlab/DiffuseKalmanSmoother3_Z.m > +++ b/matlab/DiffuseKalmanSmoother3_Z.m > @@ -91,7 +91,6 @@ Ki = zeros(mm,pp,smpl); > Kstar = zeros(mm,pp,smpl_diff); > P = zeros(mm,mm,smpl+1); > P1 = P; > -aK = zeros(nk,mm,smpl+nk); > PK = zeros(nk,mm,mm,smpl+nk); > Pstar = zeros(spstar(1),spstar(2),smpl_diff+1); Pstar(:,:,1) = Pstar1; > Pinf = zeros(spinf(1),spinf(2),smpl_diff+1); Pinf(:,:,1) = Pinf1; > @@ -162,9 +161,10 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+tril(Pstar(:,:,t),-1)'; > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squueze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*T'+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*T'; > @@ -205,11 +205,14 @@ while notsteady & t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - Pf = P(:,:,t); > + Pf = P(:,:,t); > + aK(1,:,t+1) = a1(:,t+1) > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*T' + QQ; > % notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > diff --git a/matlab/DiffuseKalmanSmootherH1.m b/matlab/DiffuseKalmanSmootherH1.m > index 362a7a6..8e16023 100644 > --- a/matlab/DiffuseKalmanSmootherH1.m > +++ b/matlab/DiffuseKalmanSmootherH1.m > @@ -98,8 +98,9 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > atilde(:,t) = a(:,t) + PZI*v(:,t); > Kinf(:,:,t) = T*PZI; > a(:,t+1) = T*atilde(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(1,:,t+1) = a(:,t+1); > + for jnk=1:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Linf(:,:,t) = T - Kinf(:,:,t)*Z; > Fstar(:,:,t) = Pstar(mf,mf,t) + H; > @@ -118,25 +119,26 @@ Pinf = Pinf(:,:,1:d); > notsteady = 1; > while notsteady & t<smpl > t = t+1; > - v(:,t) = Y(:,t) - a(mf,t) - trend(:,t); > + v(:,t) = Y(:,t) - a(mf,t) - trend(:,t); > P(:,:,t)=tril(P(:,:,t))+transpose(tril(P(:,:,t),-1)); > if rcond(P(mf,mf,t) + H) < crit > - return > - end > + return > + end > iF(:,:,t) = inv(P(mf,mf,t) + H); > PZI = P(:,mf,t)*iF(:,:,t); > atilde(:,t) = a(:,t) + PZI*v(:,t); > K(:,:,t) = T*PZI; > L(:,:,t) = T-K(:,:,t)*Z; > a(:,t+1) = T*atilde(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(1,:,t+1) = a(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T)-T*P(:,mf,t)*transpose(K(:,:,t)) + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > end > if t<smpl > - PZI_s = PZI; > + PZI_s = PZI; > K_s = K(:,:,t); > iF_s = iF(:,:,t); > P_s = P(:,:,t+1); > @@ -151,8 +153,9 @@ while t<smpl > v(:,t) = Y(:,t) - a(mf,t) - trend(:,t); > atilde(:,t) = a(:,t) + PZI_s*v(:,t); > a(:,t+1) = T*atilde(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(1,:,t+1) = a(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > t = smpl+1; > diff --git a/matlab/DiffuseKalmanSmootherH1_Z.m b/matlab/DiffuseKalmanSmootherH1_Z.m > index bbcdfd9..65fcd44 100644 > --- a/matlab/DiffuseKalmanSmootherH1_Z.m > +++ b/matlab/DiffuseKalmanSmootherH1_Z.m > @@ -108,8 +108,8 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > a(:,t+1) = T*atilde(:,t); > aK(1,:,t+1) = a(:,t+1); > % isn't a meaningless as long as we are in the diffuse part? MJ > - for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Linf(:,:,t) = T - Kinf(:,:,t)*Z; > Fstar(:,:,t) = Z*Pstar(:,:,t)*Z' + H; > @@ -141,10 +141,13 @@ while notsteady & t<smpl > L(:,:,t) = T-K(:,:,t)*Z; > a(:,t+1) = T*atilde(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*atilde(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*T'-T*P(:,:,t)*Z'*K(:,:,t)' + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -165,10 +168,13 @@ while t<smpl > atilde(:,t) = a(:,t) + PZI*v(:,t); > a(:,t+1) = T*atilde(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*atilde(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > end > t = smpl+1; > diff --git a/matlab/DiffuseKalmanSmootherH3.m b/matlab/DiffuseKalmanSmootherH3.m > index c7dc47f..afa98b5 100644 > --- a/matlab/DiffuseKalmanSmootherH3.m > +++ b/matlab/DiffuseKalmanSmootherH3.m > @@ -163,9 +163,10 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+transpose(tril(Pstar(:,:,t),-1)); > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1) > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*transpose(T)+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*transpose(T); > @@ -206,8 +207,9 @@ while notsteady & t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T) + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -233,8 +235,9 @@ while t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > ri=zeros(mm,1); > diff --git a/matlab/DiffuseKalmanSmootherH3_Z.m b/matlab/DiffuseKalmanSmootherH3_Z.m > index c01b833..5eaf948 100644 > --- a/matlab/DiffuseKalmanSmootherH3_Z.m > +++ b/matlab/DiffuseKalmanSmootherH3_Z.m > @@ -91,7 +91,6 @@ L0 = zeros(mm,mm,pp,smpl_diff); > Kstar = zeros(mm,pp,smpl_diff); > P = zeros(mm,mm,smpl+1); > P1 = P; > -aK = zeros(nk,mm,smpl+nk); > PK = zeros(nk,mm,mm,smpl+nk); > Pstar = zeros(spstar(1),spstar(2),smpl_diff+1); Pstar(:,:,1) = Pstar1; > Pinf = zeros(spinf(1),spinf(2),smpl_diff+1); Pinf(:,:,1) = Pinf1; > @@ -163,9 +162,10 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+tril(Pstar(:,:,t),-1)'; > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*T'+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*T'; > @@ -207,10 +207,13 @@ while notsteady & t<smpl > end > a1(:,t+1) = T*a(:,t); > Pf = P(:,:,t); > + aK(1,:,t+1) = a1(:,t+1); > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)) ; > + end > end > P(:,:,t+1) = T*P(:,:,t)*T' + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -238,11 +241,14 @@ while t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - Pf = P(:,:,t); > + Pf = P(:,:,t); > + aK(1,:,t+1) = a1(:,t+1); > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > end > ri=zeros(mm,1); > diff --git a/matlab/DiffuseKalmanSmootherH3corr.m b/matlab/DiffuseKalmanSmootherH3corr.m > index 800362c..cfbd826 100644 > --- a/matlab/DiffuseKalmanSmootherH3corr.m > +++ b/matlab/DiffuseKalmanSmootherH3corr.m > @@ -122,8 +122,9 @@ while newRank & t < smpl > end > end > a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + aK(1,:,t+1) = a1(:,t+1) > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*transpose(T)+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*transpose(T); > @@ -159,8 +160,9 @@ while notsteady & t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T) + QQ; > notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > @@ -186,8 +188,9 @@ while t<smpl > end > end > a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > > diff --git a/matlab/missing_DiffuseKalmanSmoother1.m b/matlab/missing_DiffuseKalmanSmoother1.m > index da7d840..5d76505 100644 > --- a/matlab/missing_DiffuseKalmanSmoother1.m > +++ b/matlab/missing_DiffuseKalmanSmoother1.m > @@ -60,7 +60,7 @@ spstar = size(Pstar1); > v = zeros(pp,smpl); > a = zeros(mm,smpl+1); > atilde = zeros(mm,smpl); > -aK = zeros(nk,mm,smpl+1); > +aK = zeros(nk,mm,smpl+nk); > iF = zeros(pp,pp,smpl); > Fstar = zeros(pp,pp,smpl); > iFinf = zeros(pp,pp,smpl); > @@ -113,9 +113,9 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > Pinf(:,:,t+1) = T*Pinf(:,:,t)*transpose(T)-T*Pinf(:,mf1,t)* ... > transpose(Kinf(:,di,t)); > end > - aK(1,:,t+1) = a(:,t+1); > - for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(1,:,t+1) = a(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > d = t; > @@ -150,7 +150,7 @@ while notsteady & t<smpl > end > aK(1,:,t+1) = a(:,t+1); > for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T)-T*P(:,mf,t)*transpose(K(:,:,t)) + QQ; > % notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > diff --git a/matlab/missing_DiffuseKalmanSmoother1_Z.m b/matlab/missing_DiffuseKalmanSmoother1_Z.m > index 097f1de..e640fa5 100644 > --- a/matlab/missing_DiffuseKalmanSmoother1_Z.m > +++ b/matlab/missing_DiffuseKalmanSmoother1_Z.m > @@ -121,7 +121,7 @@ while rank(Pinf(:,:,t+1),crit1) & t<smpl > aK(1,:,t+1) = a(:,t+1); > % isn't a meaningless as long as we are in the diffuse part? MJ > for jnk=2:nk, > - aK(jnk,:,t+jnk) = T^(jnk-1)*a(:,t+1); > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > end > d = t; > @@ -157,10 +157,13 @@ while notsteady & t<smpl > end > a(:,t+1) = T*atilde(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*atilde(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > % notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > end > diff --git a/matlab/missing_DiffuseKalmanSmoother3.m b/matlab/missing_DiffuseKalmanSmoother3.m > index 8f2a041..c4c6df3 100644 > --- a/matlab/missing_DiffuseKalmanSmoother3.m > +++ b/matlab/missing_DiffuseKalmanSmoother3.m > @@ -91,11 +91,11 @@ Pinf = zeros(spinf(1),spinf(2),smpl_diff+1); Pinf(:,:,1) = Pinf1; > Pstar1 = Pstar; > Pinf1 = Pinf; > crit = options_.kalman_tol; > -crit1 = 1.e-6; > +crit1 = 1.e-6; > steady = smpl; > rr = size(Q,1); > QQ = R*Q*transpose(R); > -QRt = Q*transpose(R); > +QRt = Q*transpose(R); > alphahat = zeros(mm,smpl); > etahat = zeros(rr,smpl); > r = zeros(mm,smpl+1); > @@ -167,16 +167,17 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+transpose(tril(Pstar(:,:,t),-1)); > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*transpose(T)+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*transpose(T); > P0=Pinf(:,:,t+1); > if newRank, > %newRank = any(diag(P0(mf,mf))>crit); > - newRank = rank(P0,crit1); > + newRank = rank(P0,crit1); > end > end > > @@ -212,10 +213,13 @@ while notsteady & t<smpl > end > a1(:,t+1) = T*a(:,t); > Pf = P(:,:,t); > + aK(1,:,t+1) = a1(:,t+1); > for jnk=1:nk, > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a1(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*transpose(T) + QQ; > % notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > diff --git a/matlab/missing_DiffuseKalmanSmoother3_Z.m b/matlab/missing_DiffuseKalmanSmoother3_Z.m > index 88cde2f..8a7313f 100644 > --- a/matlab/missing_DiffuseKalmanSmoother3_Z.m > +++ b/matlab/missing_DiffuseKalmanSmoother3_Z.m > @@ -92,7 +92,6 @@ Ki = zeros(mm,pp,smpl); > Kstar = zeros(mm,pp,smpl_diff); > P = zeros(mm,mm,smpl+1); > P1 = P; > -aK = zeros(nk,mm,smpl+nk); > PK = zeros(nk,mm,mm,smpl+nk); > Pstar = zeros(spstar(1),spstar(2),smpl_diff+1); Pstar(:,:,1) = Pstar1; > Pinf = zeros(spinf(1),spinf(2),smpl_diff+1); Pinf(:,:,1) = Pinf1; > @@ -164,9 +163,10 @@ while newRank & t < smpl > Pstar(:,:,t)=tril(Pstar(:,:,t))+tril(Pstar(:,:,t),-1)'; > end > end > - a1(:,t+1) = T*a(:,t); > - for jnk=1:nk, > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > + a1(:,t+1) = T*a(:,t); > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=2:nk > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > end > Pstar(:,:,t+1) = T*Pstar(:,:,t)*T'+ QQ; > Pinf(:,:,t+1) = T*Pinf(:,:,t)*T'; > @@ -209,10 +209,13 @@ while notsteady & t<smpl > end > a1(:,t+1) = T*a(:,t); > Pf = P(:,:,t); > - for jnk=1:nk, > + aK(1,:,t+1) = a1(:,t+1); > + for jnk=1:nk > Pf = T*Pf*T' + QQ; > - aK(jnk,:,t+jnk) = T^jnk*a(:,t); > PK(jnk,:,:,t+jnk) = Pf; > + if jnk>1 > + aK(jnk,:,t+jnk) = T*squeeze(aK(jnk-1,:,t+jnk-1)); > + end > end > P(:,:,t+1) = T*P(:,:,t)*T' + QQ; > % notsteady = ~(max(max(abs(P(:,:,t+1)-P(:,:,t))))<crit); > > ----------------------------------------------------------------------- > > Summary of changes: > matlab/DiffuseKalmanSmoother1.m | 16 ++++++++-------- > matlab/DiffuseKalmanSmoother1_Z.m | 16 +++++++++++----- > matlab/DiffuseKalmanSmoother3.m | 23 +++++++++++++++-------- > matlab/DiffuseKalmanSmoother3_Z.m | 15 +++++++++------ > matlab/DiffuseKalmanSmootherH1.m | 23 +++++++++++++---------- > matlab/DiffuseKalmanSmootherH1_Z.m | 18 ++++++++++++------ > matlab/DiffuseKalmanSmootherH3.m | 17 ++++++++++------- > matlab/DiffuseKalmanSmootherH3_Z.m | 20 +++++++++++++------- > matlab/DiffuseKalmanSmootherH3corr.m | 15 +++++++++------ > matlab/missing_DiffuseKalmanSmoother1.m | 10 +++++----- > matlab/missing_DiffuseKalmanSmoother1_Z.m | 9 ++++++--- > matlab/missing_DiffuseKalmanSmoother3.m | 18 +++++++++++------- > matlab/missing_DiffuseKalmanSmoother3_Z.m | 15 +++++++++------ > 13 files changed, 131 insertions(+), 84 deletions(-) > > > hooks/post-receive >

1 0

[Trac] #54: Add hp_filter
by Trac Dynare 10 Feb '10

10 Feb '10

#54: Add hp_filter --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: feature | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Only theoretical hp filterd moments are available in the current version. We need to add a general function for hp filtering time series and call this new function when displaying simulated moements (with option hp filter). -- Ticket URL: <https://www.dynare.org/trac/ticket/54> Dynare <http://www.dynare.org> The Dynare project

1 2

Re: [DynareDev] [Dynare Git] Dynare branch, 4.1, updated. 4.1.0-30-g7d958d5
by Stéphane Adjemian 08 Feb '10

08 Feb '10

Hi Marco, I understand now. It's true that we have nothing for this. I don't remember the reason why an error message is issued in this case, instead of a warning message. I fix it as soon as possible by adding a trap in the diffuse filter files. Best, Stéphane. > thank you for spotting this. I am guilty for introducing that trap: the > reason was if the model is non-stationary and for some parameter > values the filtver gives the error : "there is not sufficient info to > initialize the filter", this is not trapped in dsgelikelihood and > therefore we get an error break. > Obviously, one solution would be to trap the error in dsgelikelihood, > but I found easier to that there, because it was the only place where > sometimes I got that error. > I'mnot sure if that error is now trapped or we still get the error break. > > Just to let you know what was behind there. > > best wishes, have a nice week end > Marco > -- > Marco Ratto, > Euro-area Economy Modelling Centre > (http://eemc.jrc.ec.europa.eu), > Joint Research Centre > The European Commission, > TP 361, 21027 ISPRA(VA), ITALY > Tel: +39 0332 78 5639 > Fax: +39 0332 78 5733 > marco.ratto(a)jrc.ec.europa.eu

2 1

Migration to Git complete
by Sébastien Villemot 01 Feb '10

01 Feb '10

Hi, The migration to Git is complete, the wiki page has been updated with installation instructions: http://www.dynare.org/DynareWiki/GitMigration The procedure has been tested on both Linux and Windows and works smoothly (though it is possible that the documentation still needs some clarifications). You need to send me an SSH key (as described on the page) to get write access to your personal public repository. As you have seen, a new mailing list has been created for receiving information about changes merged in the central repository. Have a nice week-end, -- Sébastien Villemot

2 2

Reminder: Migration to Git tomorrow
by Sébastien Villemot 28 Jan '10

28 Jan '10

Hi, Just to remind you that we plan to migrate to Git tomorrow. As a consequence, if you have uncommitted changes in your working copy, I encourage you to commit them tonight (provided they don't break anything). However, if you don't commit them tonight, you will still be able to copy them to your future git working copy. Tomorrow, when the migration is done, I will send instructions on the list on how to setup this on your computers. In the meantime, you can refer to the wiki page I created (see my previous mail). Best -- Sébastien Villemot

1 0

Re: [DynareDev] Estimation DLL design
by Stéphane Adjemian 27 Jan '10

27 Jan '10

Hi all, For the declaration of calibrated parameters we may use the estimated_params block by specifying priors with zero variance... Or we may add dirac delta function as a new prior shape. For the choice of the prior density I agree with Michel. The user has to choose the prior variance knowing that the weight of the prior (relative to the likelihood) will depend on the sub-sample size. Obviously we could imagine a way to automatically reweight the priors, but I don't think it would be a good idea. Best, Stéphane. Le mardi 26 janvier 2010 à 13:39 +0100, Michel Juillard a écrit : > Hi George, > > > > There are however few outstanding issues to be resolved. > > > > 1.a) Is Detrend data called only once as it looks like to me now? > No. in EstimationModule, function data_filtering is called a first time > and then several time in Loop on periods 1 to NP > > > I.e. can trend depend on different draws of parmaters and different > > steady states? > yes > > > > 1.b) Also, Can trend and the constant be different for different periods? > yes > > > > 2) Can there be fixed (calibrated) parameters' sets for different > > regimes/periods? > > > Good point. This should be permitted, but we don't have provision for > it. Neither an interface for declararing changing calibrated parameters, > nor an internal representation in the preprocessor or in Matlab. > We need to think about it some more, but the resolution of this problem > will only affect the design of parameter updates > > > 3) Passing SteadyState: > > Do we need to return SS from estimation? > yes > > If so, which one since each estimation period may eventually have its > > own different SS? > > > all of them. SS is then a matrix with as many columns as there are > regimes in the model > > 4) Should we not weight prior density for the length of the period the > > parameter and its prior are valid for? > > > I don't think so. The prior density describes believes about the > possible values of a parameter irrespective of the number of periods for > which this parameter matters. If the subsample where a given paramter > matters is long, the prior will have less influence on estimation as in > a subsample that is short. But it is what we want. > > All the best, > > Michel > >

1 0

Stable 4.1 branch
by Sébastien Villemot 25 Jan '10

25 Jan '10

Hi everyone, Just to remind you that, if you fix important bugs in the trunk, you also need to fix them yourselves in the 4.1 branch (using the "svn merge" command, until we migrate to git). It's difficult for me to decide which fixes should be merged, and how the merge should be done in case of conflict, so I prefer to let you make the decision when relevant. Best, -- Sébastien Villemot

1 0

New documentation for MSBVAR interface
by Tao Zha 21 Jan '10

21 Jan '10

Dear Michel: I have revised the MSBVAR interface documentation substantially. I attach a version here. Please work on this version. Thanks, Tao ------------------

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of external functions in the model (was: Add derivatives of unknown functions in the model)
by Trac Dynare 19 Jan '10

19 Jan '10

#9: Add derivatives of external functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: houtanb Type: feature | Status: assigned Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * owner: sebastien => houtanb * status: accepted => assigned Old description: New description: An analysis is avaiable at: http://www.dynare.org/DynareWiki/ExternalFunctions -- -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

Migration to Git
by Sébastien Villemot 15 Jan '10

15 Jan '10

Hi everyone, We are planning to switch from SVN to Git in about two weeks. For more details about Git and the migration process, see: http://www.dynare.org/DynareWiki/GitMigration Also note that if you want to begin playing with Git, there is a test Git repository for Dynare, which you can retrieve with: git clone http://www.dynare.org/git/dynare-sandbox.git Note that this is only a read-only repository for testing purpose: it contains all the history of Dynare from 2005 to 2010, but it will not be modified, and you cannot push changes into it. Use it for creating a local repository and playing with it (commits, branches, merges...) Best -- Sébastien Villemot

1 0

Re: [DynareDev] [Trac] #19: Add tool to automatically write a stationary version of the model, given trends supplied by user
by Trac Dynare 08 Jan '10

08 Jan '10

#19: Add tool to automatically write a stationary version of the model, given trends supplied by user ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * milestone: => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/19#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #13: Add estimation with unexpected structural change
by Trac Dynare 08 Jan '10

08 Jan '10

#13: Add estimation with unexpected structural change ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: stepan Type: feature | Status: assigned Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * milestone: => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/13#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #9: Add derivatives of unknown functions in the model
by Trac Dynare 08 Jan '10

08 Jan '10

#9: Add derivatives of unknown functions in the model ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: feature | Status: accepted Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * milestone: => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/9#comment:4> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #18: Clean-up, streamline and documente filter/smoother routines
by Trac Dynare 08 Jan '10

08 Jan '10

#18: Clean-up, streamline and documente filter/smoother routines ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: michel Type: enhancement | Status: accepted Priority: major | Milestone: 4.2 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * owner: => michel * status: new => accepted * milestone: => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/18#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #25: Prototype of finite element method (ZLB)
by Trac Dynare 08 Jan '10

08 Jan '10

#25: Prototype of finite element method (ZLB) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Changes (by michel): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/25#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] [Trac] #23: Add Estimation DLL
by Trac Dynare 08 Jan '10

08 Jan '10

#23: Add Estimation DLL -----------------------------+---------------------------------------------- Reporter: sebastien | Owner: george Type: feature | Status: new Priority: major | Milestone: 4.3 Component: Estimation DLL | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Changes (by michel): * milestone: 4.2 => 4.3 -- Ticket URL: <https://www.dynare.org/trac/ticket/23#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

Windows 7 file Explorer crashing on encountering Matlab .mat files
by G Perendia 30 Dec '09

30 Dec '09

Hi I started encountering what appears to be an unusual problem: Windows 7 file Explorer started crashing and automatically restarting consistently on opening or browsing any directory containing Matlab .mat files! Cygwin I looked int blogs and it appear to be happening to others but mainly with media (e.g. mpeg) files. On my machine, .mat is associated to Matlab via the registry but I can not even run file to program association utility as it uses explorer to search for all file extension on the machine so it crashes too. I did not have much luck with the blogs (I already posted issue to Matlab Newsgroup blog) so I wandered if anyone of you has a suggestion how to solve this issue. PS: Cygwin, Matlab and windows commnad window have no problems browsing or reading those directories but wordpad file open similarly crashes. Best George

1 0

Release of Dynare 4.1.0
by Sébastien Villemot 23 Dec '09

23 Dec '09

Hi everyone, I uploaded the new package for Dynare 4.1.0 on the website. Houtan: could you create a Mac package, starting from the source package on the website? I think this package should contain binaries (Intel and PPC if possible) for preprocessor, dynare++, MEX for Octave, documentation, but no MEX for MATLAB. It should rather provide the build_matlab.m script and all the source files for MEX, so that users can recompile the MEX on their own machine. We can't provide binary MEX for all the various versions of MATLAB. Best, -- Sébastien Villemot

3 4

[Trac] #52: stoch_simul + hpfilter
by Trac Dynare 23 Dec '09

23 Dec '09

#52: stoch_simul + hpfilter --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- stoch_simul (order 1 and theoretical moments) crashes with hpfilter options. -- Ticket URL: <https://www.dynare.org/trac/ticket/52> Dynare <http://www.dynare.org> The Dynare project

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev