#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
#220: add a homotopy mode for simul() and for steady with endval
-----------------------+----------------------------------------------------
Reporter: sebastien | Owner:
Type: feature | Status: new
Priority: major | Milestone: 4.3
Component: General | Version:
Keywords: |
-----------------------+----------------------------------------------------
Currently homotopy only exist for steady with initval.
These features would be useful for GIMF at the IMF.
--
Ticket URL: <https://www.dynare.org/trac/ticket/220>
Dynare <http://www.dynare.org>
The Dynare project
#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
#202: conditional_variance_decomposition option fails with estimation
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner:
Type: bug | Status: new
Priority: major | Milestone:
Component: Core M-files | Version: 4.2.1
Keywords: |
--------------------------+-------------------------------------------------
It looks for the M_.sigma_e_is_diagonal flag, which is only added by the
preprocessor if the "shocks" block is present, based on the contents of
that block. In an estimation context, this field is therefore not
necessarily present.
Maybe the fix is to generate the flag in the preprocessor using the
contents of estimated_params. Comments please.
--
Ticket URL: <https://www.dynare.org/trac/ticket/202>
Dynare <http://www.dynare.org>
The Dynare project
#134: Reorganize M-structures used for storing block decomposition information
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner: ferhat
Type: enhancement | Status: new
Priority: major | Milestone: 4.2
Component: Preprocessor | Version:
Keywords: |
--------------------------+-------------------------------------------------
See the following page for the current state:
http://www.dynare.org/DynareWiki/GlobalVariableBD
--
Ticket URL: <https://www.dynare.org/trac/ticket/134>
Dynare <http://www.dynare.org>
The Dynare project
#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
#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
#135: Improve display of decision rules with EXPECTATION operator
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner: sebastien
Type: enhancement | Status: new
Priority: minor | Milestone: 4.3
Component: Preprocessor | Version:
Keywords: |
--------------------------+-------------------------------------------------
Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model,
then a new aux variable is created, and this var is a state var, which
appears in the decision rules as EXPECTATION(-1)(...) (with the dots
instead of the expression). This is not very informative. Displaying the
full expression would require to add a new writeOutput method in the
preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse,
because there are 2 aux vars: one for the operator, and the second one
which appears when removing lags of 2. It is the latter which appears in
stoch_simul. Fixing this requires to fix the orig_endo field of
M_.aux_vars in that case.
--
Ticket URL: <https://www.dynare.org/trac/ticket/135>
Dynare <http://www.dynare.org>
The Dynare project