#117: IRF: document the way they are computed at order 2 and 3
---------------------------+------------------------------------------------
Reporter: sebastien | Owner:
Type: feature | Status: new
Priority: major | Milestone: 4.2
Component: Documentation | Version:
Keywords: |
---------------------------+------------------------------------------------
--
Ticket URL: <https://www.dynare.org/trac/ticket/117>
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
#161: Under Octave, gamma priors fail when variance is too small
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner:
Type: bug | Status: new
Priority: major | Milestone: 4.2
Component: Core M-files | Version: 4.1.3
Keywords: |
--------------------------+-------------------------------------------------
This is reproducible on file RBC_Est.mod distributed with the user guide,
which has two gamma priors.
The problem is related to a bug in Octave:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493869
It may also affect beta priors which rely on gaminv() function.
A minimal solution would be to give a sensible error message to the user,
so that he knows he has to increase the variance.
A better solution would be to reimplement gaminv.
--
Ticket URL: <https://www.dynare.org/trac/ticket/161>
Dynare <http://www.dynare.org>
The Dynare project
#157: histval + stoch_simul(periods=...) + forecast gives wrong result
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner:
Type: bug | Status: new
Priority: major | Milestone: 4.2
Component: Core M-files | Version: 4.1.3
Keywords: |
--------------------------+-------------------------------------------------
If there is a histval block, followed by stoch_simul using empirical
simulations ("periods" option), then the information provided by histval
is lost (the "oo_.endo_simul" structure, which contains the histval
information, is completely rewritten).
A subsequent forecast command wrong results, since it will not use histval
as starting point.
--
Ticket URL: <https://www.dynare.org/trac/ticket/157>
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
#122: Lower and upper bounds on priors used for two purposes
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner:
Type: bug | Status: new
Priority: minor | Milestone: 4.2
Component: Core M-files | Version: 4.1.2
Keywords: |
--------------------------+-------------------------------------------------
The p3 and p4 parameters of estimated_params are currently used for two
distinct purposes:
- specifying the domain of definition of the prior (uniform, generalized
beta and gamma)
- restricting the optimization for the posterior mode on a sub-domain of
the definition of the prior
This double usage of the same values is confusing, and makes some cases
impossible to describe in a MOD file (example: restricting the
optimization on a subdomain of the interval of a uniform).
The fix is probably to distinguish these two usages in the MOD file by
introducing a new syntax for restricting the optimization, and reflecting
that change in the M code.
--
Ticket URL: <https://www.dynare.org/trac/ticket/122>
Dynare <http://www.dynare.org>
The Dynare project