Dev July 2009

dev@dynare.org

5 participants
15 discussions

model derivatives with respect to parameters
by Michel Juillard 19 Aug '09

19 Aug '09

Dear Nikolay, we have started to work on producing the derivatives with respect to parameters. We are planing to create a new function, that will return a 3-dimensional array, by equation, variable and parameter. You could then select one parameter and squeeze the array in the parameter dimension to obtain a matrix of Jacobian derivatives with respect to a given parameter. Do you see any problem with this implementation? We should be able to provide in about two weeks. All the best, Michel

4 6

Re: [DynareDev] lyapunov kalman filter options
by Michel Juillard 30 Jul '09

30 Jul '09

G. Perendia wrote: > Dear Michel > > Should we include Matlab disclyap_fast.m into (next major release of) Dynare > Matlab suite as an alternative or replacement for lyapunov_symm.m and shall > we/I then also: > > we should just replace lyapunov_symm by (renamed) disclyap_fast.m > a) change Matlab disclyap_fast.m to accept tolerance as parameter and > include it into Dynare Matlab suite, > yes > b) change its name, > yes > d) prepare and include C++ disclyap_fast_dll.dll as separate module, again > as alternative to lyapunov_symm.m, > no, let's not multiply the DLLs called from Matlab. We will use the C code as part of a big DLL that performs all the estimation code > d) change its name too, > e) change DsgeLikelihood.m to use either Matlab and/or C++ disclyap_fast.m > > This is a bit complicated. Dsgelikelihood (and dsgelikelihood_hh) calls lyapunov_symm for stationary models. kalman_algo = 1 or 2 Equivalent code is present in dsgelikelihood.m for nonstationary models kalman_algo = 3 or 4 Best Michel > Best regards > > George > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 29, 2009 7:36 PM > Subject: Re: [DynareDev] lyapunov kalman filter options > > > Sounds good, thanks > > Michel > > G. Perendia wrote: > >> Dear Michel (et al) >> >> On my slower laptop I run few tests and got timings roughly on lines of >> > the > >> following timings for an 8x8 T matrix and 10,000 loops: >> >> Matlab: >> >> lyapunov_symm.m time = 19.2270 s >> Pearlman Matlab disclyap_fast.m time = 13.0280 s >> >> New C++ disclyap_fast DLL: >> >> disclyap_fast_dll_time = 7.8010 sec for tolerance= 1e-16 >> disclyap_fast_dll_time = 6.5600 sec for tolerance= 1e-12 >> >> Best regards >> >> George >> >> ----- Original Message ----- >> From: "Michel Juillard" <michel.juillard(a)ens.fr> >> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "List for Dynare >> developers" <dev(a)dynare.org> >> Sent: Wednesday, July 29, 2009 10:33 AM >> Subject: Re: [DynareDev] lyapunov kalman filter options >> >> >> Tanks for the update. >> The false value when A contains unit root is a fault of design. The >> information on which columns are useable is in the list of stationary >> variables, >> >> Best >> >> Michel >> >> G. Perendia wrote: >> >> >>> Dear Michel and Stephane >>> >>> Re the below warning: the results from lyapunov_symm.m seem now correct - >>> >>> >> It >> >> >>> seems that my Matlab variables memory was corrupted and after a reboot >>> > and > >>> restart it seems ok now - sorry for the alarm. >>> >>> It however reports (an incorrect ) X=[0's] instead of indeterminate or >>> >>> >> NaN >> >> >>> if I pass a=I. >>> >>> PS: and I still need to test and debug new C++lyapunov because it may >>> > have > >>> been causing the variable corruption. >>> >>> >>> Best regards >>> >>> George >>> >>> ----- Original Message ----- >>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>> Cc: "List for Dynare developers" <dev(a)dynare.org> >>> Sent: Wednesday, July 29, 2009 9:27 AM >>> Subject: lyapunov kalman filter options >>> >>> >>> >>> >>> >>>> I would use lyapunov_tol = 1e-12 >>>> (in the example disclyap_fat.m, the criterium is 1e-16) >>>> and >>>> kalman_tol = 1e-12 >>>> >>>> Both options should be accessible to users and obtained from >>>> options_. The initialization should take place in >>>> > global_initialization.m > >>>> Best >>>> >>>> Michel >>>> >>>> >>>> >>>> >>>> >>>>> Errata: >>>>> 1) it is options_.lyapunov_complex_threshold=1e-15 that is passed in >>>>> >>>>> >>>>> >>> calls >>> >>> >>> >>>>> to the >>>>> existing lyapunov_symm.m and I can use that as tolerance instead the >>>>> original 1e-6 if needed. >>>>> >>>>> Warning: >>>>> >>>>> If I pass a=T=[0] and b=RQR'~0 to lyapunov_symm.m, I get result Pstar >>>>> >>>>> >>>>> >>> very >>> >>> >>> >>>>> different from b although the solution to Lyapunov x-a*x*a' = b is >>>>> >>>>> >>>>> >>> x=b=RQR' >>> >>> >>> >>>>> and both, the new C++ and old matlab disklyap_fast return X=b=RQR as >>>>> solution!! >>>>> >>>>> Best regards >>>>> >>>>> George >>>>> >>>>> ----- Original Message ----- >>>>> From: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>>> To: "Michel Juillard" <michel.juillard(a)ens.fr>; "Stéphane Adjemian" >>>>> <stephane.adjemian(a)gmail.com> >>>>> Sent: Wednesday, July 29, 2009 7:46 AM >>>>> Subject: Re: measurement errors + steady KF >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Michel, Stephane >>>>>> >>>>>> What tolerances should we use to pass: >>>>>> >>>>>> 1)for the new fast iterative C++ Lyapunov solution convergence check >>>>>> >>>>>> if max( max( abs( P1 - P0 ) ) )>tol >>>>>> >>>>>> The original Joe Pearlman's matlab code used 1e-6. which is same as >>>>>> >>>>>> >>>>>> >>> Dynare >>> >>> >>> >>>>>> default ricatti_tol (also used for a similar purpose in calls to the >>>>>> existing lyapunov_symm.m.). So, shall we use the riccati_tol or set a >>>>>> separate, lyapunov_tol one at the same default level? >>>>>> >>>>>> 2) and, as per below, for the Old style DiffuseLikelihood.m like >>>>>> > Pstar > >>>>>> convergence/differences, that has been built into the C++KF i.e.: >>>>>> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >>>>>> where crit is options_.kalman_tol = 1.0000e-012 - I guess we can >>>>>> >>>>>> >>>>>> >>>>>> >>>>> continue >>>>> >>>>> >>>>> >>>>> >>>>>> to use the same >>>>>> though the new likelihood/kalman_filter*.m suite uses riccati_tol >>>>>> >>>>>> >>>>>> >>> instead >>> >>> >>> >>>>>> but for F convergence check. >>>>>> >>>>>> Best regards >>>>>> >>>>>> George >>>>>> Mob. +44(0)7951415480 >>>>>> artilogica(a)btconnect.com >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "Stéphane >>>>>> >>>>>> >>>>>> >>> Adjemian" >>> >>> >>> >>>>>> <stephane.adjemian(a)gmail.com> >>>>>> Sent: Tuesday, July 14, 2009 11:47 PM >>>>>> Subject: Re: measurement errors + steady KF >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I don't know. This is something that we need to discuss with >>>>>>> > Stephane. > >>>>>>> All the best, >>>>>>> >>>>>>> Michel >>>>>>> >>>>>>> G. Perendia wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks Michel >>>>>>>> >>>>>>>> I am finishing algorithm for checking if KF P (and/or K) are steady >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> for >>>>> >>>>> >>>>> >>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> C++KF. >>>>>>>> >>>>>>>> Old DiffuseLikelihood.m uses Pstar differences, i.e.: >>>>>>>> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >>>>>>>> where crit is options_.kalman_tol = 1.0000e-012 >>>>>>>> >>>>>>>> whilst the new kalman_filter.m uses K to check: >>>>>>>> notsteady = max(max(abs(K-oldK))) > riccati_tol; >>>>>>>> where >>>>>>>> K = Pstar*Z'*invF; >>>>>>>> and options_.riccati_tol= 1.0000e-006 >>>>>>>> >>>>>>>> Which tolerance (and check) should I use for C++KF? >>>>>>>> I have already built a system using Pstar -oldPstar and that works >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> well >>>>> >>>>> >>>>> >>>>> >>>>>> but >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> question is which tolerance to use since riccati seems sufficient >>>>>>>> > for > >>>>>>>> >>>>>>>> >>>>> P >>>>> >>>>> >>>>> >>>>> >>>>>>>> difference too. >>>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> George >>>>>>>> Mob. +44(0)7951415480 >>>>>>>> artilogica(a)btconnect.com >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>>>>>> Sent: Tuesday, July 14, 2009 6:57 AM >>>>>>>> Subject: Re: measurement errors >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi George, >>>>>>>>> >>>>>>>>> it is like for exogenous variables. If GDP is an endogenous >>>>>>>>> > variable > >>>>>>>>> estimated_params; >>>>>>>>> stderr GDP, uniform_pdf,,,0,1; >>>>>>>>> .... >>>>>>>>> end; >>>>>>>>> >>>>>>>>> will introduce a measurement error on GDP. >>>>>>>>> >>>>>>>>> Best >>>>>>>>> >>>>>>>>> Michel >>>>>>>>> G. Perendia wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Dear Michel >>>>>>>>>> >>>>>>>>>> For testing Part Info (and the other) Kalman filters, I would need >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> to >>>>> >>>>> >>>>> >>>>> >>>>>>>>>> set situation with measurement errors so that H~=0. >>>>>>>>>> >>>>>>>>>> Can you please let me know how one specifies measurement errors >>>>>>>>>> in Dynare for estimation so that H ~ =0? >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> George >>>>>>>>>> artilogica(a)btconnect.com <mailto:artilogica@btconnect.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> _______________________________________________ >> Dev mailing list >> Dev(a)dynare.org >> http://www.dynare.org/cgi-bin/mailman/listinfo/dev >> >> >> >> _______________________________________________ >> Dev mailing list >> Dev(a)dynare.org >> http://www.dynare.org/cgi-bin/mailman/listinfo/dev >> >> >> > > > _______________________________________________ > Dev mailing list > Dev(a)dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > >

2 2

Re: [DynareDev] lyapunov kalman filter options
by Michel Juillard 29 Jul '09

29 Jul '09

Tanks for the update. The false value when A contains unit root is a fault of design. The information on which columns are useable is in the list of stationary variables, Best Michel G. Perendia wrote: > Dear Michel and Stephane > > Re the below warning: the results from lyapunov_symm.m seem now correct - It > seems that my Matlab variables memory was corrupted and after a reboot and > restart it seems ok now - sorry for the alarm. > > It however reports (an incorrect ) X=[0's] instead of indeterminate or NaN > if I pass a=I. > > PS: and I still need to test and debug new C++lyapunov because it may have > been causing the variable corruption. > > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "G. Perendia" <george(a)perendia.orangehome.co.uk> > Cc: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 29, 2009 9:27 AM > Subject: lyapunov kalman filter options > > > >> I would use lyapunov_tol = 1e-12 >> (in the example disclyap_fat.m, the criterium is 1e-16) >> and >> kalman_tol = 1e-12 >> >> Both options should be accessible to users and obtained from >> options_. The initialization should take place in global_initialization.m >> >> Best >> >> Michel >> >> >> >>> Errata: >>> 1) it is options_.lyapunov_complex_threshold=1e-15 that is passed in >>> > calls > >>> to the >>> existing lyapunov_symm.m and I can use that as tolerance instead the >>> original 1e-6 if needed. >>> >>> Warning: >>> >>> If I pass a=T=[0] and b=RQR'~0 to lyapunov_symm.m, I get result Pstar >>> > very > >>> different from b although the solution to Lyapunov x-a*x*a' = b is >>> > x=b=RQR' > >>> and both, the new C++ and old matlab disklyap_fast return X=b=RQR as >>> solution!! >>> >>> Best regards >>> >>> George >>> Mob. +44(0)7951415480 >>> artilogica(a)btconnect.com >>> >>> ----- Original Message ----- >>> From: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>> To: "Michel Juillard" <michel.juillard(a)ens.fr>; "Stéphane Adjemian" >>> <stephane.adjemian(a)gmail.com> >>> Sent: Wednesday, July 29, 2009 7:46 AM >>> Subject: Re: measurement errors + steady KF >>> >>> >>> >>> >>>> Hi Michel, Stephane >>>> >>>> What tolerances should we use to pass: >>>> >>>> 1)for the new fast iterative C++ Lyapunov solution convergence check >>>> >>>> if max( max( abs( P1 - P0 ) ) )>tol >>>> >>>> The original Joe Pearlman's matlab code used 1e-6. which is same as >>>> > Dynare > >>>> default ricatti_tol (also used for a similar purpose in calls to the >>>> existing lyapunov_symm.m.). So, shall we use the riccati_tol or set a >>>> separate, lyapunov_tol one at the same default level? >>>> >>>> 2) and, as per below, for the Old style DiffuseLikelihood.m like Pstar >>>> convergence/differences, that has been built into the C++KF i.e.: >>>> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >>>> where crit is options_.kalman_tol = 1.0000e-012 - I guess we can >>>> >>>> >>> continue >>> >>> >>>> to use the same >>>> though the new likelihood/kalman_filter*.m suite uses riccati_tol >>>> > instead > >>>> but for F convergence check. >>>> >>>> Best regards >>>> >>>> George >>>> Mob. +44(0)7951415480 >>>> artilogica(a)btconnect.com >>>> >>>> ----- Original Message ----- >>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "Stéphane >>>> > Adjemian" > >>>> <stephane.adjemian(a)gmail.com> >>>> Sent: Tuesday, July 14, 2009 11:47 PM >>>> Subject: Re: measurement errors + steady KF >>>> >>>> >>>> >>>> >>>>> I don't know. This is something that we need to discuss with Stephane. >>>>> >>>>> All the best, >>>>> >>>>> Michel >>>>> >>>>> G. Perendia wrote: >>>>> >>>>> >>>>>> Thanks Michel >>>>>> >>>>>> I am finishing algorithm for checking if KF P (and/or K) are steady >>>>>> >>>>>> >>> for >>> >>> >>>> the >>>> >>>> >>>>>> C++KF. >>>>>> >>>>>> Old DiffuseLikelihood.m uses Pstar differences, i.e.: >>>>>> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >>>>>> where crit is options_.kalman_tol = 1.0000e-012 >>>>>> >>>>>> whilst the new kalman_filter.m uses K to check: >>>>>> notsteady = max(max(abs(K-oldK))) > riccati_tol; >>>>>> where >>>>>> K = Pstar*Z'*invF; >>>>>> and options_.riccati_tol= 1.0000e-006 >>>>>> >>>>>> Which tolerance (and check) should I use for C++KF? >>>>>> I have already built a system using Pstar -oldPstar and that works >>>>>> >>>>>> >>> well >>> >>> >>>> but >>>> >>>> >>>>>> question is which tolerance to use since riccati seems sufficient for >>>>>> >>>>>> >>> P >>> >>> >>>>>> difference too. >>>>>> >>>>>> Best regards >>>>>> >>>>>> George >>>>>> Mob. +44(0)7951415480 >>>>>> artilogica(a)btconnect.com >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>>>> Sent: Tuesday, July 14, 2009 6:57 AM >>>>>> Subject: Re: measurement errors >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi George, >>>>>>> >>>>>>> it is like for exogenous variables. If GDP is an endogenous variable >>>>>>> >>>>>>> estimated_params; >>>>>>> stderr GDP, uniform_pdf,,,0,1; >>>>>>> .... >>>>>>> end; >>>>>>> >>>>>>> will introduce a measurement error on GDP. >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> Michel >>>>>>> G. Perendia wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Dear Michel >>>>>>>> >>>>>>>> For testing Part Info (and the other) Kalman filters, I would need >>>>>>>> >>>>>>>> >>> to >>> >>> >>>>>>>> set situation with measurement errors so that H~=0. >>>>>>>> >>>>>>>> Can you please let me know how one specifies measurement errors >>>>>>>> in Dynare for estimation so that H ~ =0? >>>>>>>> Best regards >>>>>>>> >>>>>>>> George >>>>>>>> Mob. +44(0)7951415480 >>>>>>>> artilogica(a)btconnect.com <mailto:artilogica@btconnect.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> a >>>>> >>>>> >>>>> >>> >>> >>> >>> >> > > > >

2 2

lyapunov kalman filter options
by Michel Juillard 29 Jul '09

29 Jul '09

I would use lyapunov_tol = 1e-12 (in the example disclyap_fat.m, the criterium is 1e-16) and kalman_tol = 1e-12 Both options should be accessible to users and obtained from options_. The initialization should take place in global_initialization.m Best Michel > Errata: > 1) it is options_.lyapunov_complex_threshold=1e-15 that is passed in calls > to the > existing lyapunov_symm.m and I can use that as tolerance instead the > original 1e-6 if needed. > > Warning: > > If I pass a=T=[0] and b=RQR'~0 to lyapunov_symm.m, I get result Pstar very > different from b although the solution to Lyapunov x-a*x*a' = b is x=b=RQR' > and both, the new C++ and old matlab disklyap_fast return X=b=RQR as > solution!! > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > ----- Original Message ----- > From: "G. Perendia" <george(a)perendia.orangehome.co.uk> > To: "Michel Juillard" <michel.juillard(a)ens.fr>; "Stéphane Adjemian" > <stephane.adjemian(a)gmail.com> > Sent: Wednesday, July 29, 2009 7:46 AM > Subject: Re: measurement errors + steady KF > > > >> Hi Michel, Stephane >> >> What tolerances should we use to pass: >> >> 1)for the new fast iterative C++ Lyapunov solution convergence check >> >> if max( max( abs( P1 - P0 ) ) )>tol >> >> The original Joe Pearlman's matlab code used 1e-6. which is same as Dynare >> default ricatti_tol (also used for a similar purpose in calls to the >> existing lyapunov_symm.m.). So, shall we use the riccati_tol or set a >> separate, lyapunov_tol one at the same default level? >> >> 2) and, as per below, for the Old style DiffuseLikelihood.m like Pstar >> convergence/differences, that has been built into the C++KF i.e.: >> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >> where crit is options_.kalman_tol = 1.0000e-012 - I guess we can >> > continue > >> to use the same >> though the new likelihood/kalman_filter*.m suite uses riccati_tol instead >> but for F convergence check. >> >> Best regards >> >> George >> Mob. +44(0)7951415480 >> artilogica(a)btconnect.com >> >> ----- Original Message ----- >> From: "Michel Juillard" <michel.juillard(a)ens.fr> >> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "Stéphane Adjemian" >> <stephane.adjemian(a)gmail.com> >> Sent: Tuesday, July 14, 2009 11:47 PM >> Subject: Re: measurement errors + steady KF >> >> >> >>> I don't know. This is something that we need to discuss with Stephane. >>> >>> All the best, >>> >>> Michel >>> >>> G. Perendia wrote: >>> >>>> Thanks Michel >>>> >>>> I am finishing algorithm for checking if KF P (and/or K) are steady >>>> > for > >> the >> >>>> C++KF. >>>> >>>> Old DiffuseLikelihood.m uses Pstar differences, i.e.: >>>> notsteady = ~(max(max(abs(Pstar-oldPstar)))<crit); >>>> where crit is options_.kalman_tol = 1.0000e-012 >>>> >>>> whilst the new kalman_filter.m uses K to check: >>>> notsteady = max(max(abs(K-oldK))) > riccati_tol; >>>> where >>>> K = Pstar*Z'*invF; >>>> and options_.riccati_tol= 1.0000e-006 >>>> >>>> Which tolerance (and check) should I use for C++KF? >>>> I have already built a system using Pstar -oldPstar and that works >>>> > well > >> but >> >>>> question is which tolerance to use since riccati seems sufficient for >>>> > P > >>>> difference too. >>>> >>>> Best regards >>>> >>>> George >>>> Mob. +44(0)7951415480 >>>> artilogica(a)btconnect.com >>>> >>>> ----- Original Message ----- >>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>> Sent: Tuesday, July 14, 2009 6:57 AM >>>> Subject: Re: measurement errors >>>> >>>> >>>> >>>> >>>>> Hi George, >>>>> >>>>> it is like for exogenous variables. If GDP is an endogenous variable >>>>> >>>>> estimated_params; >>>>> stderr GDP, uniform_pdf,,,0,1; >>>>> .... >>>>> end; >>>>> >>>>> will introduce a measurement error on GDP. >>>>> >>>>> Best >>>>> >>>>> Michel >>>>> G. Perendia wrote: >>>>> >>>>> >>>>>> Dear Michel >>>>>> >>>>>> For testing Part Info (and the other) Kalman filters, I would need >>>>>> > to > >>>>>> set situation with measurement errors so that H~=0. >>>>>> >>>>>> Can you please let me know how one specifies measurement errors >>>>>> in Dynare for estimation so that H ~ =0? >>>>>> Best regards >>>>>> >>>>>> George >>>>>> Mob. +44(0)7951415480 >>>>>> artilogica(a)btconnect.com <mailto:artilogica@btconnect.com> >>>>>> >>>>>> >>>> >>>> >>>> >>> a >>> >>> > > > > >

1 0

next step
by Michel Juillard 23 Jul '09

23 Jul '09

Dear George, the next step in the C implementation of the estimation routine is to have a compiled version of the Lyapunov equation solver. The corresponding Matlab code is in lyapunov_symm.m or around lines 185-242 of DsgeLikelihood.m. I probably got the idea of the algorithm in "Numerical Recepees in C++" or "Matrix Computations", this last one by Golub and van Loan. lyapunov_symm.m returns the covariance matrix (and the list of stationary variables) while in DsgeLikelihood, we keep the Schur decomposition of the state space transition matrix in order to have a quasi-triangular transition matrix in the Kalman filter (matrix T) and the Schur vectors to build matrix Z. Currently we only use it for the diffuse filter, but there is no reason not to use for the regular filter if it is more efficient. I see two ways to implement it. Write it from scratch in C++ using direct calls to the necessary Lapack functions and/or use RECSY http://www.cs.umu.se/~isak/recsy/ (we need of course to evaluate it first). The problem/advantage of RECSY is that it uses parallel computing via OpenMP, but currently (as of 2008 versions) MKL distributed with Matlab is incompatible with OpenMP (see the discussion lead by Stephane Adjemian a few months ago). My feeling is that building the estimation DLL will be easier with a Lyapunov solver built from scratch and that we can keep dealing with RESY for further improvments of efficiency. Note that there must be a Lyapunov solver in dynare++, but I'm afraid that it will be plagued with the same problems as the Kalman filter and my feeling is that it takes longer to modify it than to write clean code from the start. Please tell me your thoughts, Best Michel

1 0

Fast steady state computation
by Sébastien Villemot 13 Jul '09

13 Jul '09

Hi everyone, I have added a new option to the "steady" command, called "block_mfs". This option does the following: * it performs a normalization and a block decomposition of the static model * then for each block it computes the minimum feedback set (MFS) of variables, in order to reduce the size of the steady-state sub-problem; in the current state of the code, variables which are not written in a normalized form (x=f(y) where x is not in y), are automatically included in the MFS The option is currently operational. Tested on EAGLE model, under Octave, it is 3 times faster than the traditional steady command. With MATLAB on Karaba, I hit a MATLAB crash which needs further investigation. The current performance bottle-neck is that we only exploit hand-written normalizations in the model. Ferhat has already added some code which tries linear transformations in order to put more equations in normalized form; I will incoporate this to the current code. Further improvements needs to be done: * adding temporary terms to the generated *_static.m file * improving the performance of the preprocessor (it is a bit slow on big models such as GIMF) I will be on vacations for about one month, but I will read my e-mail. All the best, -- Sébastien Villemot

1 0

Preprocessor and g++
by Sébastien Villemot 11 Jul '09

11 Jul '09

Hi, In my last commit, I use an extension of the C++ standard template library that is only implemented in g++ (and also in a few other compilers). Practically, that means that currently the preprocessor cannot be compiled with a compiler different from g++. Is this a problem for you? If it is, then I can provide an alternative implementation of this extension, for compilers other than g++. -- Sébastien Villemot

2 1

Re: [DynareDev] DiffuseLikelihod kalman routines
by G. Perendia 08 Jul '09

08 Jul '09

Hi Marco (et al) I uploaded the compatibility and consistency changes outlined below I made to the trunk and the branch versions of: DiffuseLikelihoodH3 DiffuseLikelihood3 DiffuseLikelihoodH3_Z DiffuseLikelihood3_Z DiffuseLikelihoodH3corr DsgeLikelihood_hh I also added lik to the output of both instances of DiffuseLikelihoodH3corr.m as it seem needed by DsgeLikelihood_hh.m and, removed the incompatible .5* in front of "lik" in the both instances of DsgeLikelihood_hh.m, i.e. llik=[-lnprior; lik(start:end)] instead llik=[-lnprior; .5*lik(start:end)] I did not however correct the call to the non-existent DiffuseLikelihoodH3corr_Z in the latest, trunk, version of DsgeLikelihood_hh.m as I am not yet fully sure of the intention. If the older versions need to be reinstated, that can be done from SVN archive (and I have kept copies too). Let me know if that is OK. Best regards George ----- Original Message ----- From: "G. Perendia" <george(a)perendia.orangehome.co.uk> To: "List for Dynare developers" <dev(a)dynare.org> Sent: Wednesday, July 08, 2009 2:30 PM Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > Hi All (and Marco!) > > 1) I made and committed the changes to both the trunk and the branch > versions of DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and released > locked routines earlier today. > > 2) However, things are never so simple and the resulting chain reaction / > snowball goes on: > > Looking at the other DiffuseLikelihood* functions called within > DsgeLikilihood_hh that initially did not need the bug fix: > > DiffuseLikelihoodH3_Z > DiffuseLikelihood3_Z > DiffuseLikelihoodH3corr_Z > > The first two use inherently correct but in the context of DsgeLikilihood_hh > incompatible calculation of the lik array which contains all log(2*pi) in > the last (sample+1) element i.e. > lik(smpl+1) = smpl*pp*log(2*pi); > > so that LIK : > > LIK = .5*(sum(lik(start:end))-(start-1)*lik(smpl+1)/smpl); > > is correctly calculated within the functions but that yields probably > incorrect one for the llik returned from DsgeLikilihood_hh in its last line: > > llik=[-lnprior; .5*lik(start:end)] > > I.e. it will contain too many log(2*pi) 's when start>1. > > 3) Also, the new kalman_filter and corrected DiffuseLikelihood ones all have > > lik = (lik + pp*log(2*pi))/2 > > so the lik is already multiplied with 0.5! > and that is incompatible with the llik calculation in DsgeLikilihood_hh. > > I guess, for consistency, I should make some of the changes to the other > Diffuse functions now too, i.e. replace: > lik(smpl+1) = smpl*pp*log(2*pi); > with > lik = (lik + pp*log(2*pi))/2 > as in all other kalman_filter ones > > and , in DsgeLikilihood_hh, probably replace > > llik=[-lnprior; .5*lik(start:end)] > with > llik=[-lnprior; lik(start:end)] > > This is even more urgent since the new version of > kalman_filter.m, also called within DsgeLikilihood_hh, also pre- halves lik > array! > > 3) The third called function does not exist in the matlab directory but > DiffuseLikelihoodH3corr.m (without "_Z") does and that has the same > compatibility problem. > > Hence, DsgeLikilihood_hh also needs to be corrected to refer to an existing > function (I guess it was a typo in DsgeLikilihood_hh) and I can make that > correction too if that is OK. > > Best regards > > George > > ----- Original Message ----- > From: "G. Perendia" <george(a)perendia.orangehome.co.uk> > To: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 08, 2009 12:24 PM > Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > > > Hi > > The trunk ones are still being used by DsgeLikilihood_hh and will be needed > for 4.1 and the branch ones appear to be just their identical copies (e.g. > diff reports no differences), and so will they be fixed by mere copying - > just in case. > > If that is OK , I will lock them this afternoon and let you know when I > finish and unlock them. > > Regards > George > > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "List for Dynare developers" <dev(a)dynare.org> > Sent: Wednesday, July 08, 2009 12:08 PM > Subject: Re: [DynareDev] DiffuseLikelihod kalman routines > > > I beg to disagree. It's not a good idea to leave bugs behind. I had > already forgotten these ones when we decided to release 4.0.4 > I don't think it is big changes either > > Best > > Michel > > Sébastien Villemot wrote: > > Le mercredi 08 juillet 2009 à 10:56 +0100, G. Perendia a écrit : > > > >> I am scheduling some bug fixing changes to both the trunk and the > >> branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like > >> to avoid any potential edit conflicts. > >> > > > > Just to mention that we have decided that there would be no more Dynare > > release in the 4.0.x. We are now focusing our energies on the next major > > release, 4.1, by the end of the summer if everything goes well. > > > > So it's not necessary to fix the 4.0 branch. > > > > Best, > > > > > > > _______________________________________________ > Dev mailing list > Dev(a)dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > _______________________________________________ > Dev mailing list > Dev(a)dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev >

1 0

DiffuseLikelihod kalman routines
by G. Perendia 08 Jul '09

08 Jul '09

Hi I am scheduling some bug fixing changes to both the trunk and the branch DiffuseLikelihood1, H1, 1_Z and H1_Z.m routines and would like to avoid any potential edit conflicts. Is anyone planning or doing work on those routines and is it ok to put a temporary Tortoise SVN lock on them, e.g. for today or tomorrow? Best regards George

4 6

Andrea's files
by Michel Juillard 07 Jul '09

07 Jul '09

Here are the files in a new message. Best Michel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev July 2009