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