August 2011 - Dev - dynare.org

[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] #135: Improve display of decision rules with EXPECTATION operator
by Trac Dynare 06 Jun '12

06 Jun '12

#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

1 1

[Trac] #159: gamrnd.m (in matlab/missing/stats): implement selection of alternative methods (3rd argument)
by Trac Dynare 06 Jun '12

06 Jun '12

#159: gamrnd.m (in matlab/missing/stats): implement selection of alternative methods (3rd argument) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: stepan Type: enhancement | Status: new Priority: minor | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/159> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #174: Remove options_.planner_discount from preprocessor and .m files
by Trac Dynare 06 Jun '12

06 Jun '12

#174: Remove options_.planner_discount from preprocessor and .m files --------------------------+------------------------------------------------- Reporter: houtanb | Owner: Type: bug | Status: new Priority: minor | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- This is no longer necessary and can be cleaned out of the code. -- Ticket URL: <https://www.dynare.org/trac/ticket/174> Dynare <http://www.dynare.org> The Dynare project

1 4

[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

[Trac] #112: Metropolis: add the possibility for the user to give an arbitrary matrix for the variance of the jump proposal
by Trac Dynare 06 Jun '12

06 Jun '12

#112: Metropolis: add the possibility for the user to give an arbitrary matrix for the variance of the jump proposal --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: feature | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Feature suggested by Fabio Canova at the Dynare Conference 2010. -- Ticket URL: <https://www.dynare.org/trac/ticket/112> Dynare <http://www.dynare.org> The Dynare project

1 4

[Trac] #164: consider using bvar provided by Zha and Waggoner instead of our own
by Trac Dynare 05 Jun '12

05 Jun '12

#164: consider using bvar provided by Zha and Waggoner instead of our own --------------------------+------------------------------------------------- Reporter: houtanb | Owner: Type: feature | Status: new Priority: major | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Their code provides a superset of ours. -- Ticket URL: <https://www.dynare.org/trac/ticket/164> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #184: Auxiliary variables for leads.
by Trac Dynare 05 Jun '12

05 Jun '12

#184: Auxiliary variables for leads. --------------------------+------------------------------------------------- Reporter: stepan | Owner: houtanb Type: enhancement | Status: new Priority: major | Milestone: 4.3 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- The last loop in add_auxiliary_variables is highly inefficient. The the residuals of the static model are evaluated (many times) to compute the the steady state levels of the auxiliary variables. But in the preprocessing stage, the expressions of the auxiliary variables (in terms of the endogenous variables) are known. The preprocessor should write a routine defining the auxiliary variables as a function of the endogenous variables. Depending on the current options, this routine may be a matlab function, a mex or bytecode. With such a function we won't need to infer the steady state of the auxiliaries from the residuals of the static model... -- Ticket URL: <https://www.dynare.org/trac/ticket/184> Dynare <http://www.dynare.org> The Dynare project

1 2