Dev March 2011

dev@dynare.org

5 participants
66 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev March 2011