December 2009 - Dev - dynare.org

Re: [DynareDev] [Trac] #12: Compute temporary terms when using option block_mfs of steady
by Trac Dynare 16 Dec '09

16 Dec '09

#12: Compute temporary terms when using option block_mfs of steady ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: enhancement | Status: closed Priority: minor | Milestone: 4.1 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: Fixed in r3244. -- Ticket URL: <https://www.dynare.org/trac/ticket/12#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #64: Fix USE_DLL option at order 2
by Trac Dynare 14 Dec '09

14 Dec '09

#64: Fix USE_DLL option at order 2 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Currently the MEX returns a hessian made of 3 columns (sparse representation: two columns for indices, one column for values). A call to sparse() function needs to be added in dr1.m when USE_DLL option is used. Maybe a field options_.use_dll should be added by the preprocessor to facilitate the test in dr1.m. -- Ticket URL: <https://www.dynare.org/trac/ticket/64> Dynare <http://www.dynare.org> The Dynare project

3 3

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

11 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: closed Priority: major | Milestone: 4.1 Component: K-order DLL | Version: Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by sebastien): * status: accepted => closed * resolution: => fixed -- Ticket URL: <https://www.dynare.org/trac/ticket/3#comment:6> Dynare <http://www.dynare.org> The Dynare project

1 0

3rd order and USE_DLL option under Windows
by Sébastien Villemot 11 Dec '09

11 Dec '09

Hi, I made a change in the preprocessor so that 3rd order approx, and USE_DLL option, which both require the on-the-fly compilation of a MEX file. These options now correctly work with both Cygwin and Microsoft Visual C++ under Windows. For those of you who use Cygwin, you need to update your mexopts.bat with the one I just put in the SVN in windows/ subdirectory. I also wrote a wiki page on the topic: http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation Best -- Sébastien Villemot

1 0

Release of 4.1
by Sébastien Villemot 11 Dec '09

11 Dec '09

Hi, We are planning to release 4.1 very soon, before Christmas. I have reassigned to milestone 4.2 various Trac tickets which were initially planned for 4.1, and that we won't have the time to deal with before Christmas. Please pay particular attention not to break anything in the trunk, until we create the branch for 4.1. Also note that before creating the 4.1 branch, I plan to reindent all the C++ and Matlab code. Best -- Sébastien Villemot

1 0

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