April 2010 - Dev - dynare.org

[Trac] #72: 2nd and 3rd order approximation of purely backward and forward models
by Trac Dynare 29 May '12

29 May '12

#72: 2nd and 3rd order approximation of purely backward and forward models --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: feature | Status: new Priority: minor | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- - need to write specialized code for 2nd and 3rd order approximation of purely backward and forward models -- Ticket URL: <https://www.dynare.org/trac/ticket/72> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #63: new option instrument
by Trac Dynare 20 Apr '12

20 Apr '12

#63: new option instrument ---------------------------+------------------------------------------------ Reporter: michel | Owner: michel Type: enhancement | Status: new Priority: major | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ Document the new option "instrument" for ramsey_policy in reference manual and write wiki page on using *_steadystate.m file with ramsey_policy -- Ticket URL: <https://www.dynare.org/trac/ticket/63> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #94: Remove obsolete code dealing with more than one lead and/or one lag
by Trac Dynare 26 Nov '11

26 Nov '11

#94: Remove obsolete code dealing with more than one lead and/or one lag --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: minor | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- In the resolution of stochastic models, this code is no longer necessary since the preprocessor removes any lead and lag of more than one. But this code should be kept in the deterministic case, since the preprocessor doesn't do the transformation. -- Ticket URL: <https://www.dynare.org/trac/ticket/94> Dynare <http://www.dynare.org> The Dynare project

1 3

[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] #87: fix order of integration in univariate filter/smoother
by Trac Dynare 31 Jan '11

31 Jan '11

#87: fix order of integration in univariate filter/smoother --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/87> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #56: Faster smoother for large models
by Trac Dynare 31 Jan '11

31 Jan '11

#56: Faster smoother for large models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/56> Dynare <http://www.dynare.org> The Dynare project

1 3

[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] #75: Fix command "calib" or remove it
by Trac Dynare 04 Jan '11

04 Jan '11

#75: Fix command "calib" or remove it --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- The "calib" command (and its associated command "calib_var") are recognized by the preprocessor, but are probably not working, and are not documented in the reference manual. This should be fixed, or the commands be removed. -- Ticket URL: <https://www.dynare.org/trac/ticket/75> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #95: the "simul" option of "stoch_simul" simulates on more periods than required
by Trac Dynare 02 Jan '11

02 Jan '11

#95: the "simul" option of "stoch_simul" simulates on more periods than required --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: trivial | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- The point is that the oo_.exo_simul vector has length options_.periods+M_.maximum_lag+M_.maximum_lead (see make_ex_.m). This makes sense in a deterministic context, but in a stochastic context there it should only be of length options_.periods. This makes the oo_.endo_simul of length 2*M_.maximum_lag+options_.periods+M_.maximum_lead (because it adds initial conditions), while it should be of length M_.maximum_lag+options_.periods. This is not a big issue since one can just truncate the extra periods, but this confuses some users. -- Ticket URL: <https://www.dynare.org/trac/ticket/95> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #78: Problem with derivatives of power function at point zero
by Trac Dynare 17 Dec '10

17 Dec '10

#78: Problem with derivatives of power function at point zero --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- There is currently a problem with the derivatives of the power function f(x)=x^p^ at the point x=0. The power function f(x)=x^p^ well defined for x>0 and for any p, since f(x)=e^p*ln(x)^. The domain of definition of this function can be extended to x=0 with the following rules when p>0: * f(0)=0 * f is differentiable k times at x=0, where k is the integer part of p, and f'^k^=0 And when p is an strictly positive integer, the function is differentiable at any order, and its derivative at zero is zero. When p is a constant, the preprocessor computes the right value of the derivatives at x=0, using simplifications rules. But when p is a parameter, the preprocessor will not give the right value for integer values of p. Currently the derivation rule is applied by the preprocessor, the k-th derivative of f(x) is equal to: p*(p-1)*...*(p-k+1)*x^p-k^ So when p is an integer, the (p+1)-th derivative computed at x=0 will give a NaN (0 times infinity), while it ought to be zero. This problem typically arises in models with adjustment costs where the curvature (the exponent) of the cost is a integer parameter, and the cost is zero at steady state. The solution is probably to create, in the preprocessor, a new operator called "derivative of power function at order k". This operator would output a code like that in the M-file: {{{ dxp=deriv(x,p,k) % The k-th derivative of x^p if (p > 0) && (abs(p - round(p)) < 1e-12 && k >= p dxp = 0; else dxp = x^(p-k); for i=1:k-1 dxp = dxp*p; p = p-1; end end }}} -- Ticket URL: <https://www.dynare.org/trac/ticket/78> Dynare <http://www.dynare.org> The Dynare project

1 7