Dev May 2010

dev@dynare.org

1 participants
37 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] #102: forecast graphs in manual
by Trac Dynare 15 Jun '12

15 Jun '12

#102: forecast graphs in manual ---------------------------+------------------------------------------------ Reporter: michel | Owner: michel Type: bug | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ The graphs of forecasts with uncertainty about the parameters have changed but we didn't modify the user manual and the user guide -- Ticket URL: <https://www.dynare.org/trac/ticket/102> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #59: add errors to print_info.m
by Trac Dynare 14 Jun '12

14 Jun '12

#59: add errors to print_info.m --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: bug | Status: new Priority: critical | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- info(1) == 43 (covariance matrix of shocks is not positive definite) should be added to print_info.m We need to check that all error numbers that can be present in info(1) are taken care of. We need to check with grep info *.m -- Ticket URL: <https://www.dynare.org/trac/ticket/59> Dynare <http://www.dynare.org> The Dynare project

1 7

[Trac] #58: Implement constrained parameters for osr
by Trac Dynare 07 Jun '12

07 Jun '12

#58: Implement constrained parameters for osr --------------------------+------------------------------------------------- Reporter: sebastien | Owner: michel Type: feature | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/58> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #77: provide all solve_algo for all representations of the model
by Trac Dynare 06 Jun '12

06 Jun '12

#77: provide all solve_algo for all representations of the model --------------------------+------------------------------------------------- Reporter: ferhat | Owner: ferhat Type: enhancement | Status: new Priority: major | Milestone: 4.2 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- For the moment, only some combinations of block, bytecode and stack_solve_algo are available. Allow for the possibility to use all the algorithms for all model representation. -- Ticket URL: <https://www.dynare.org/trac/ticket/77> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #85: Estimation is not deterministic: a seed should be explictly given to random number generator
by Trac Dynare 06 Jun '12

06 Jun '12

#85: Estimation is not deterministic: a seed should be explictly given to random number generator --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- Currently MOD files doing estimation are not deterministic: different runs of the same MOD files don't give the same results, since the seed for random number generator is not the same accross runs. The easy way to fix that is to set the seed in dynare.m. There would be a default value for the seed, or it could be changed through an option/command. A more subtle way would be to have a seed reset at the top of every major function (estimation, stoch_simul). We need to decide which way is the best. -- Ticket URL: <https://www.dynare.org/trac/ticket/85> Dynare <http://www.dynare.org> The Dynare project

5 15

[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] #79: Some Dynare++ tests fail
by Trac Dynare 06 Jun '12

06 Jun '12

#79: Some Dynare++ tests fail -----------------------+---------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: Component: Dynare++ | Version: 4.1.0 Keywords: | -----------------------+---------------------------------------------------- Some unit tests of Dynare++ fail: * in the integ library * in the kord library Moreover, the kord tests take a VERY long time. We need to check with Ondra how to fix these tests. -- Ticket URL: <https://www.dynare.org/trac/ticket/79> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #86: check matrix power used in forecast
by Trac Dynare 06 Jun '12

06 Jun '12

#86: check matrix power used in forecast --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- taking large matrix power in forecast step of the Kalman smoother routines is expensive, but probably more accurate than recursive multiplications. - investigate more accuracy issue - factorise matrix decomposition for matrix power -- Ticket URL: <https://www.dynare.org/trac/ticket/86> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #83: persistent variables must be cleared at the beginning of a Dynare run
by Trac Dynare 06 Jun '12

06 Jun '12

#83: persistent variables must be cleared at the beginning of a Dynare run --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: minor | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- persistent variables in *.m files trigger hard to understand errors if the user run successively two different *.mod files with 'noclearall' option. Whenever a function uses persistent variables, there should be an explicit initialize option and not rely on empty persistent variables as, for example, priordens.m currently does. -- Ticket URL: <https://www.dynare.org/trac/ticket/83> Dynare <http://www.dynare.org> The Dynare project

1 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev May 2010