Dev September 2009

dev@dynare.org

8 participants
36 discussions

[Trac] #35: Putting "shocks" before "endval" leads to wrong results
by Trac Dynare 30 Jul '12

30 Jul '12

#35: Putting "shocks" before "endval" leads to wrong results --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- In a deterministic setup with both temporary and permanent shocks, the order of the {{{shocks}}} and {{{endval}}} blocks matter. Actually, putting {{{shocks}}} before {{{endval}}} leads to wrong results. {{{shocks}}} uses {{{set_shocks.m}}}, which fills in {{{oo_.exo_simul}}}; the point is that, if {{{endval}}} has not been used, this structure is empty, so {{{set_shocks}}} fills it, at date of shocks, for ''all'' the exogenous, and using the ''initial'' steady state value. When {{{simul}}} is finally called, it completes {{{oo_.exo_simul}}} with the ''final'' exogenous steady state, but only for those periods which have no temporary shocks. So at the dates with temporary shocks, the value of exogenous which are permanently shocked is wrong. A quick fix is to forbid the use of {{{shocks}}} before {{{endval}}}. A cleaner fix is to modify {{{set_shocks.m}}} so that it only sets values for the exogenous which are temporarily shocked, and leaves {{{NaN}}} for other exogenous. It would be {{{simul}}}'s job to fill in the holes. -- Ticket URL: <https://www.dynare.org/trac/ticket/35> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #38: Create an entry point in bytecode interpreter for use by k-order DLL
by Trac Dynare 06 Jun '12

06 Jun '12

#38: Create an entry point in bytecode interpreter for use by k-order DLL --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- First, support for k-order derivatives computation needs to be added to the preprocessor. Second, a storage mechanism for these needs to be added in the bytecode generation. Third, the bytecode interpreter should provide two C functions: * one for retrieving the number of non-zero elements (NNZE) in the k-order derivative (accross all equations) * one which would pass on the derivatives to the caller. Its arguments would be: * the order of derivation (k) * a (double*) vector, allocated by the caller, of length the NNZE * a (int*) matrix, of size NNZE times (k+1): the first column is the equation number, the others are the variables indices (ordered in non- decreasing order: the symmetric elements are not duplicated) -- Ticket URL: <https://www.dynare.org/trac/ticket/38> Dynare <http://www.dynare.org> The Dynare project

1 5

[Trac] #31: identification code
by Trac Dynare 29 Sep '11

29 Sep '11

#31: identification code --------------------------+------------------------------------------------- Reporter: michel | Owner: Marco Type: feature | Status: new Priority: major | Milestone: 4.2-alpha2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/31> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #37: Automatic generation of _steadystate.m file from initval block
by Trac Dynare 26 Jan '11

26 Jan '11

#37: Automatic generation of _steadystate.m file from initval block --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- The idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block. This would be particularly useful for estimating models for which the analytical form of the steady state is known. -- Ticket URL: <https://www.dynare.org/trac/ticket/37> Dynare <http://www.dynare.org> The Dynare project

1 11

[Trac] #40: Test M_.params at the top of the main functions.
by Trac Dynare 17 Nov '10

17 Nov '10

#40: Test M_.params at the top of the main functions. --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN). -- Ticket URL: <https://www.dynare.org/trac/ticket/40> Dynare <http://www.dynare.org> The Dynare project

1 3

[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] #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] #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

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

[Trac] #36: Write a Wiki page on the various incompatibilities accross MATLAB versions
by Trac Dynare 23 Nov '09

23 Nov '09

#36: Write a Wiki page on the various incompatibilities accross MATLAB versions ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ This wiki page should only document changes relevant to Dynare, in particular with respect to MEX files. All MATLAB release notes since R14 are available on: http://www.mathworks.com/access/helpdesk/help/techdoc/ -- Ticket URL: <https://www.dynare.org/trac/ticket/36> Dynare <http://www.dynare.org> The Dynare project

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev September 2009