Dev April 2010

dev@dynare.org

7 participants
46 discussions

[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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev April 2010