Dev

dev@dynare.org

3402 discussions

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

11 Dec '09

#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: ---------------------------+------------------------------------------------ Changes (by sebastien): * milestone: 4.1 => 4.2 -- Ticket URL: <https://www.dynare.org/trac/ticket/5#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] Proposed specification for estimation functions
by G. Perendia 10 Dec '09

10 Dec '09

PS: Re naming suggestions: As M_.params is updated too in the 50-123 block, name update_params is also adequate though something like updateQHMparams() would still be more precise . ----- Original Message ----- From: G. Perendia To: List for Dynare developers Sent: Monday, September 21, 2009 10:27 AM Subject: Re: [DynareDev] Proposed specification for estimation functions Thanks Stephane Re: 3&4) Sorry for confusion: Overlapping variables refer to the results of Kalman from the previous period sub-sample block such as a(t|t-1) and P(t|t-1) and will not they be used as starting point entries for the next period block estimation. However, I am not sure if then their "meaning" for the next sub-sample may be distorted by separate data filtering (DataPreparation) for that sub-sample. I am however also not sure if I can take this into C++ DsgeLikelihood as yet in full - there are many unresolved items (and even more not yet properly understood by me, see below) - but I can at least start building bones for its future integration. E.g. have quite a few more questions: 5) How are we going to calculate and report overall (or sub-sample?) likelihood(s) to the parameter optimising/sampling DsgeLikelihood driving function (eg csminwel, fminunc or MCMC MH) and how to get it to optimise/sample parameters for different sub-samples? Or, is the parameter differentiation parametric/functional and planned to be included in "update_parameters" block? 6) How will the system know which name structure to target ID1 if "ID1 is a n by 1 vector of indices targeting to the (parameter, exogenous variable or endogenous variable) names (in M_.param_names, M_.exo_names and M_.endo_names" 7) If "the considered subsamples for different parameters may be different", then I believe we need to split the data subsamples and the estimation blocks into shorter common sub-samples. I.e., when you say: "xparam1 is a column n by 1 vector holding the current values of the estimated parameters" does "current" mean value at time t such that max(StartPeriod)< t < min(EndPeriod) for the set? 8) Are priors time-dependent, defined for each sub-sample (or the time slot of the parameter? Are they updated on the run, conditional on previous sub-sample or preset? 9) what do nv*_id nv* by 1 vector of integers represent? If shock IDs, then how the nv* shocks/errors can be linked to individual params' periods. I.e. are they time dependent too and if not, what is their role in this time-slot-dependent structure? 10) In the loop you refer to "NP" as number of periods: "LOOP on periods 1 to NP" but in the structure (lowercase) "np" seem to refer to the number of deep parameters- use of same word/literal (despite of the case difference) may be a bit confusing 11) which optimiser is the method of indirect inference in Dynare? May I also make some suggestions? re 4) Block of lines 50-123 updates and checks shocks and obs. errors cov kalman matrices Q and H using relevant subsets of the parameters vector xparam1 (but not changing xparam1). I believe a more precise and descriptive name for the block (e.g. updateQH() or updateShocksAndErrorMatrices() or something on those lines) may be less confusing with e.g. generating or updating the whole new set of all parameters. Also, DataCleanup, DataDetrend or DataPreparation instead of "data_filtering()" I believe may be less confusing with e.g. Kalman filtering. I hope this helps to clarify rather than confuse the issues even more. Best regards George ----- Original Message ----- From: Stéphane Adjemian To: List for Dynare developers Sent: Friday, September 18, 2009 12:09 PM Subject: Re: [DynareDev] Proposed specification for estimation functions Hi, I am not sure that it would be a good idea to implement the unexpected breaks stuff in the c++ version of the DsgeLikelihood... Because it's a new feature and we have no experience with it. I Changed Period1 to StartPeriod and Period2 to EndPeriod, thanks for the suggestion. In the data filtering step we remove the "deterministic part" of the data (constant and linear trends), so that we do not have to treat this in the kalman filter recursions. This is already done like this in the matlab version of DsgeLikelihood. I do not understand 3) and 4). What is an overlapping variable. The parameter update step corresponds to block between lines 50 to 123 in DsgeLikelihood.m I think that we do have a c version of the sims optimization routine (provided by Tao Zha). Best, Stéphane. 2009/9/18 G. Perendia <george(a)perendia.orangehome.co.uk> Hi I would like to start implementing period-dependent likelihood calculation within the new C++ DsgeLikelihood but that will add a bit of time. 1) I suggest that parameters description is defined by Start (or StartPeriod) and End (or EndPeriod) instead of a.. Period1 (beginning of sub-period) a.. Period2 (end of sub-period) respectively because we may have more than 2 periods and using terms Period1 and 2 as delimiters for other periods can bee a bit confusing in the context (as it did confuse me for a start) . 2) What is data_filtering (for period 1) step as opposed to Kalman filter - is it Kalman smoother? We have no working C++ implementation for smoother as yet. 3) Would it be right to say that the new period divided likelihood estimation requires overlapping variables Y(-/+n) for n>0 among the sub-period blocks? 4) What is parameters update? Is it param likelihood, hill climbing optimisation (or MCMC step) for each sub-period block separately (conditional on the previous period block?)? We do not have working optimiser in C++ yet. 4) Would the interim period-blocks' Kalman inputs be a(t|t-1) and P(t|t-1) as well as overlapping variables Y(-/+n) for n>0 from previous block Kalman output? Best regards George _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev -- Stéphane Adjemian CEPREMAP & Université du Maine Tel: (33)1-43-13-62-39 ---------------------------------------------------------------------------- _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

2 7

Re: [DynareDev] [Trac] #3: Add interface to k-order DLL, up to order 3, using model compiled in C
by Trac Dynare 09 Dec '09

09 Dec '09

#3: Add interface to k-order DLL, up to order 3, using model compiled in C --------------------------+------------------------------------------------- Reporter: sebastien | Owner: michel Type: feature | Status: accepted Priority: major | Milestone: 4.1 Component: K-order DLL | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Comment(by sebastien): Almost done as of r3216. The last thing to do is to try to make Microsoft Visual C++ work with k_order_solver, this is mandatory for 64-bit MATLAB for Windows. This involves modifying the mexopts.bat for testing purposes, and if successful, update the preprocessor (maybe with a preprocessor option to switch between g++/MSVC), and the reference manual. -- Ticket URL: <https://www.dynare.org/trac/ticket/3#comment:5> Dynare <http://www.dynare.org> The Dynare project

1 0

k_order_perturbation under Windows
by Michel Juillard 08 Dec '09

08 Dec '09

k_order_perturbation DLL works under Windows XP and Octave when compiled under Cygwin (with gcc-4), but it is necessary to add -D_WIN32 when compiling, in order to avoid the dlopen/dlclose functions. If these functions are present, Octave refuses to load the DLL. I'm going to check with Matlab now Best Michel

3 8

Re: [DynareDev] SWZ Question regarding max_lag_length r
by Michel Juillard 04 Dec '09

04 Dec '09

Hi Houtan, > Dear Michel and Sébastien, > > Everything is coded and tested for the svar_identification. However, I > want to check my implementation of the maximum lag length (r) with > you. In order to obtain r, I have introduced a temporary variable > entitled max_endo_lag in ParsingDriver, which updates this variable > every time add_model_variable() is called. Is this the best way to do > this or can you think of a better way. I should point out that it is > my understanding that the variables entitled like max_endo_lag in > DynamicModel do not actually contain the original maximum endogenous > lag in the model (which is what I understand should be the value for > r). Otherwise, I would have simply included dynamic_model in the > SvarIdentificationStatement class. > this is true. (S)VAR will be the only type of models that are left with lags on more than one period. > One problem with the implementation I have chosen is that we would > need to ensure that the model block is declared before the > svar_identification block in the .mod file. I noticed that, currently, > though in the manual we are instructed as to the proper declaration > order within the .mod file (i.e. vars, params, model, ..., > estimation/stoch_simul), this order is not enforced within Dynare. > In fact, certain mixes of this ordering work (e.g. putting the initval > statement above the model block) whereas certain orderings fail > without any sort of descriptive message (e.g., ... shock block, > initval block, model block ...). In my opinion, enforcing some sort of > ordering and exiting with a warning to the user would be nicer than > simply allowing dynare to crash. > > So, if the implementation described in paragraph 1 that obtains the > maximum endogenous variable lag length by constantly updating this > variable in add_model_variable is correct, we must ensure that the > model block has been declared before the svar_identification block so > that this variable will have been set. That said, I welcome any ideas > that would solve this problem more efficiently than the method > described herein. They are in fact very few strict order dependencies that need to be enforced and checked. The manual gives more an advice than an obligation. For, (S)VAR, we don't need the model block and we need to relax this requirement in the preprocessor. In this particular case, I don't think that we need to enforce any consistency. It makes sense for example to declare identification restrictions on many lags and then decide to estimate with a smaller number of lags in the VAR, without asking the user to adjust the SVAR_IDENTIFICATION block. You probably need to create an SvarIdentificationStatement class similar to i.e. InitParamStatement in NumericalInitialization.hh that record all the identification restrictions before the output stage. You can declare there a private variable with the maximum number of lags used in the svar_identification block. Sebastien, what do you think? Best Michel You need however the maximum number of lags used in the SVAR_IDENTIFICATION block to dimension Ri

3 5

expectational operators
by G. Perendia 04 Dec '09

04 Dec '09

Hi Can anyone let me know what is the status of implementation of the expectational operators (in particular E_t,t ) and when will they be ready for use in our dev version as they are needed for full implementation of Partial Information? Also, is their syntax going to follow closely what is on the wiki page NewOperators? Best regards George

3 3

SWZ
by Michel Juillard 03 Dec '09

03 Dec '09

I have updated SWZ in SVN to include changes that were already present in what I presented last week. I have added to the wiki a detailed description of the interface for SVAR exclusion restriction in http://www.dynare.org/DynareWiki/SvarExclusionInterface the Qi and Ri matrices should be implemented by Houtan in the preprocessor. Karl and Stephane have just to write a small identification/exclusions.m and identification/lower_cholesky.m All the best, Michel

3 7

k_order_perturbation under Windows
by Michel Juillard 03 Dec '09

03 Dec '09

Configuring my Matlab compiler as LCC doesn't work. I can't load fs2000k2_dynamic.mexw32 even directly from Matlab. George, Sebastien, You should first verify that the DLLs createed with use_dll work indeed with Matlab before attemping to debug k_order_perturbation.cpp Even if it isn't that, the problem is most likely with the calling of Dynamic DLL. This is the only part that is different under Windows and Linux. Best Michel

2 1

Re: [DynareDev] Fw: [Trac] #60: Fix memory leaks in k_order_perturbation DLL
by Sébastien Villemot 03 Dec '09

03 Dec '09

Le lundi 30 novembre 2009 à 17:50 +0000, G. Perendia a écrit : > Is there any more info on this issue? Please see my comment associated to the #60 issue on the trac system. Please answer there if you want to continue the discussion. -- Sébastien Villemot

3 6

Re: [DynareDev] C++ DsgeLikelihood and estimation issues
by G. Perendia 02 Dec '09

02 Dec '09

Hi Sebastien I now have a pretty stable working prototype of C++ DsgeLikelihood suitable for initial indicative performance tests. Unfortunately, during the lengthy debugging process, I realised I had to take out some performance improvers built as overloads for the GeneralMatrix copy() method, originally for improving the Kalman Filter performance, since they were breaking (now integrated) K-order-perturbation and hence I will need to devise and develop some alternative performance booster methods. However, some very rough performance comparison tests with fs2000 model even with such degraded KF indicate to be pretty promising and worth of the further effort: whilst 1000 loop calling Matlab DsgeLikelihood.m (all with same parameters) takes randomly somewhere between 40 and 50 sec, calling the equivalent CalcLikelihood method from within parent C++ mexFunction (together with constructing its parent class once as it would be done by the C++ estimation) takes approx. 10 sec (thus, less than 1/4th of time). This was run on an old and slower machine but the relative advantage is pretty portable. That, (together with some additional performance boosting) may result in a rather substantial time saving for whole MLE/MCMC estimation! Best regards George

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev