April 2012 - Dev - dynare.org

[Trac] #198: update set_dynare_seed.m to use new function rng
by Trac Dynare 20 Apr '12

20 Apr '12

#198: update set_dynare_seed.m to use new function rng --------------------------+------------------------------------------------- Reporter: houtanb | Owner: houtanb Type: bug | Status: new Priority: minor | Milestone: 4.3 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- NB: rng() introduced in Matlab R2011a -- Ticket URL: <https://www.dynare.org/trac/ticket/198> Dynare <http://www.dynare.org> The Dynare project

1 5

[Trac] #190: expectation operator conflicts with ramsey policy
by Trac Dynare 20 Apr '12

20 Apr '12

#190: expectation operator conflicts with ramsey policy --------------------------+------------------------------------------------- Reporter: michel | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- ramsey_policy does not provide the same results with expectation operator or if one adds the auxiliary variable/equation by hand I suspect that the auxiliary variables and the Lagrange mutlipliers are not entered in the right order or Ramsey policy fails if other auxiliary variables are already present in the model -- Ticket URL: <https://www.dynare.org/trac/ticket/190> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #161: Under Octave, gamma priors fail when variance is too small
by Trac Dynare 20 Apr '12

20 Apr '12

#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

1 2

Status of testsuite in master branch
by Sébastien Villemot 20 Apr '12

20 Apr '12

*************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 169 tests PASSED out of 169 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 167 tests PASSED out of 167 tests run *************************************** A full log can be found on karaba in '/var/tmp/dynare-master-check-qqk0vF5Rfk.log'.

1 0

Status of testsuite in 4.2 branch
by Sébastien Villemot 20 Apr '12

20 Apr '12

*************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 150 tests PASSED out of 150 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 148 tests PASSED out of 148 tests run *************************************** A full log can be found on karaba in '/var/tmp/dynare-4.2-check-n0izPRTMNK.log'.

1 0

[Trac] #246: finish ms-sbvar
by Trac Dynare 19 Apr '12

19 Apr '12

#246: finish ms-sbvar ------------------------------------+--------------------------------------- Reporter: houtanb | Owner: houtanb Type: enhancement | Status: new Priority: major | Milestone: 4.3 Component: Markov-Switching SBVAR | Version: Keywords: | ------------------------------------+--------------------------------------- * Incorporate Tao's git * in ms_estimation, return A0, A+, Zeta, Q without calling mex_ms_convert_free_parameters, which is just a copy of Dan's code (same reason we rewrote irf, forecast, vd) -- Ticket URL: <https://www.dynare.org/trac/ticket/246> Dynare <http://www.dynare.org> The Dynare project

1 3

Status of testsuite in master branch
by Sébastien Villemot 19 Apr '12

19 Apr '12

*************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 169 tests PASSED out of 169 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 167 tests PASSED out of 167 tests run *************************************** A full log can be found on karaba in '/var/tmp/dynare-master-check-W19oxOtRWN.log'.

1 0

Status of testsuite in 4.2 branch
by Sébastien Villemot 19 Apr '12

19 Apr '12

*************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 150 tests PASSED out of 150 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 148 tests PASSED out of 148 tests run *************************************** A full log can be found on karaba in '/var/tmp/dynare-4.2-check-kjiW26txz7.log'.

1 0

[Trac] #249: bug in dynare_estimation_1.m or documentation
by Trac Dynare 18 Apr '12

18 Apr '12

#249: bug in dynare_estimation_1.m or documentation ---------------------+------------------------------------------------------ Reporter: houtanb | Owner: Type: bug | Status: new Priority: major | Milestone: 4.3 Component: General | Version: 4.2.5 Keywords: | ---------------------+------------------------------------------------------ There is a discrepancy between the documentation for mode_compute = 0 in dynare.texi which reads The mode isn't computed. mode_file option must be specified and the if statement on line 118 of dynare_estimation_1.m: if isequal(options_.mode_compute,0) && isempty(options_.mode_file)... First reported here: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3709 -- Ticket URL: <https://www.dynare.org/trac/ticket/249> Dynare <http://www.dynare.org> The Dynare project

1 4

Dynare 5 Preprocessor Evaluation Rules
by Houtan Bastani 18 Apr '12

18 Apr '12

Hello, It seems as though it would be good to discuss the evaluation rules for the Dynare 5 language on the list before going too far with the prototype. To animate this discussion, a simple series of commands in the new language would be useful: a <- 1; b <- a + 1; a <- 2; model { endogenous c; ... equations { b = c*...; ... } } Basically, we need to determine how to evaluate b in this situation: 1) In the statement, b <- a + 1;, should b be evaluated to hold the value 2 or should it hold the symbolic value "a + 1"? 1a) If the answer is 2, should we allow for symbolic storage as well? I.e., the user could write something of the form: b <- sym(a) + 1; if they wanted to store the symbolic value "a + 1"? 1b) If the answer is "a + 1", should we allow for some type of forced evaluation notion to make b take the value 2? I.e., something of the form b <- eval(a) + 1;? NB: We could replace sym and eval by whatever we wanted (some languages use a preceding $ sign or quote). The idea here is mainly to decide the functionality we want to support (i.e. both 1a and 1b or just one or the other) as well as the default functionality (either 1a or 1b), but if people have strong preferences for/against a certain delimiter, they should be stated. 2) In model-related blocks (model, calibration, initval, etc), should b in this case evaluate to 2, "a+1" or 3? 2a) If 2, this means that 1a from above holds 2b) If "a+1" this means that 1b from above holds 2c) If 3, this means that 1b from above holds but that, in model-type blocks, programming variables are evaluated by default (ie, b has the value "a+1" until it is used, at which point the last available value of a is looked up, in this case 2, and b is evaluated giving 3) NB: as above, we need to decide what the default behavior will be, whether or not we will enable all behaviors listed or others I missed, and, if enabling all behaviors, what delimiters we will use to do so (e.g. $, ', eval(), etc) 3) Finally, we must decide whether to support model variable names that overlap with programming variable names. For example, in this case, would it be ok to have endogenous a; or endogenous b;? Maybe it will lead to bugs in people's code to have this option. At the same time, since we're asking users to keep track of different types of variables in their mod files (i.e. programming variables versus model variables) as well as the scope of those variables (for loops for example) it seems quite natural to support this feature. Best, Houtan

5 8