Dev November 2009

dev@dynare.org

8 participants
36 discussions

[Trac] #55: Finalize the generic parallelization system
by Trac Dynare 03 Nov '10

03 Nov '10

#55: Finalize the generic parallelization system --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- See http://www.dynare.org/DynareWiki/ParallelDynare for the remain subtasks. -- Ticket URL: <https://www.dynare.org/trac/ticket/55> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #45: Implement resid() with "block" option without "bytecode"
by Trac Dynare 17 Sep '10

17 Sep '10

#45: Implement resid() with "block" option without "bytecode" --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/45> Dynare <http://www.dynare.org> The Dynare project

1 1

[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

[Trac] #32: Report MATLAB crashes on Linux/64 to Mathworks
by Trac Dynare 10 Mar '10

10 Mar '10

#32: Report MATLAB crashes on Linux/64 to Mathworks --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- On Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX). See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB. The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64. As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on. We need to report this to Mathworks. -- Ticket URL: <https://www.dynare.org/trac/ticket/32> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #60: Fix memory leaks in k_order_perturbation DLL
by Trac Dynare 09 Mar '10

09 Mar '10

#60: Fix memory leaks in k_order_perturbation DLL -------------------------+-------------------------------------------------- Reporter: sebastien | Owner: george Type: bug | Status: new Priority: minor | Milestone: Component: K-order DLL | Version: Keywords: | -------------------------+-------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/60> Dynare <http://www.dynare.org> The Dynare project

1 6

[Trac] #54: Add hp_filter
by Trac Dynare 10 Feb '10

10 Feb '10

#54: Add hp_filter --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: feature | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Only theoretical hp filterd moments are available in the current version. We need to add a general function for hp filtering time series and call this new function when displaying simulated moements (with option hp filter). -- Ticket URL: <https://www.dynare.org/trac/ticket/54> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #52: stoch_simul + hpfilter
by Trac Dynare 23 Dec '09

23 Dec '09

#52: stoch_simul + hpfilter --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- stoch_simul (order 1 and theoretical moments) crashes with hpfilter options. -- Ticket URL: <https://www.dynare.org/trac/ticket/52> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block)
by Trac Dynare 21 Dec '09

21 Dec '09

#44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/44> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #48: Incorrect treatment of log-linear transformation for purely backward looking models
by Trac Dynare 19 Dec '09

19 Dec '09

#48: Incorrect treatment of log-linear transformation for purely backward looking models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- In dr1.m, log-linear test and the log-linear transformation of the model ghx and ghu matrices at line 449 are not reached for a purely backward looking model, because of a return statement at line 266 -- Ticket URL: <https://www.dynare.org/trac/ticket/48> Dynare <http://www.dynare.org> The Dynare project

1 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev November 2009