Dev January 2015

dev@dynare.org

4 participants
20 discussions

newrat
by Johannes Pfeifer 12 Mar '15

12 Mar '15

Hi Marco, I am trying to factorize the mode-finding code to make it reusable in other parts of Dynare. But I am having a hard time with newrat in master. The reason is that newrat is the only optimizer that endogenously changes other options used inside of the objective function. I would really like to get rid of this behavior as it makes the generic passing of input arguments to objective functions impossible. One always needs to make sure that the updated options is passed. To be specific, the problem in master derives from the fact that the analytic Hessian requires options_.kalman_algo to be either 2 or 4. If this is not the case, newrat sets one of these values. My proposal to remedy this would be to only allow using newrat without options_.analytic_derivation when kalman_algo=2 or kalman_algo=4. That is, when not using analytical derivatives the user must at least specify a Kalman algo that allows for analytical derivatives. Such a check would make changing the options redundant. Or do you envision cases where people want an analytical Hessian based univariate filters while wanting to compute the likelihood in mode-finding based numerical derivatives derived from the multivariate Kalman filter. An additional issue that popped up: currently, newrat with analytical_derivation seems to be broken for most Kalman algorithms. Thus, I cannot test the features/changes I propose. I created a pull request with a unit test for these issues. I attach the files you need to trace out the errors. Best, Johannes

2 5

submodules in Dynare
by Houtan 13 Feb '15

13 Feb '15

Hello, If I should have any spare time this week, I wanted to work on https://github.com/DynareTeam/dynare/issues/811. Looking into this has brought up several questions. If I understand correctly, the idea of moving dates and dseries into their own repositories was that they can be used as standalone programs. As such, we want to permit people who can benefit from this code to use it directly instead of having to download Dynare as a whole. In essence, we're treating them as libraries, which I think is a good idea. But, as it's setup now, dseries is not a standalone program. In order to make it a standalone program, we'd need to add dates as a submodule of this program and probably have a configuration script that adds the dates repository to the Matlab/Octave path. At least, that's how I'd like to set up reporting: add dates and dseries as submodules to reporting so that someone could clone the reporting repository, initialize its submodules and use it as a standalone program. Doing so would not present a problem to Dynare users as Dynare could still include a dates submodule, a dseries submodule that contains a dates submodule, and a reporting submodule that contains both a dseries and dates submodule. As long as the git clone or the git submodule init are not issued with the --recursive switch, the nested submodules will not be brought in and hence the code will not be duplicated. Furthermore, I think we should discuss the location of submodules within Dynare. Currently, they're in several places: 1) contrib 2) matlab/utilities/tests 3) matlab/modules This is confusing. Though I don't have a strong opinion as to the logic we should impose on the submodules we include, I believe there should be a logic. Should all external submodules be included in contrib? should all internal matlab submodules be included in matlab/modules? Should all matlab tests be included in tests/modules (matlab/utilities/tests has to be changed, in my opinion)? It would be nice if we could make a decision about the organization of the submodules within Dynare as a group so that, going forward, we have a coherent structure that does not evolve organically but rather in an organized and logical way. Best, Houtan

4 19

Status of testsuite in master branch
by dynbot＠cepremap.org 29 Jan '15

29 Jan '15

1 0

Status of testsuite in master branch
by dynbot＠cepremap.org 28 Jan '15

28 Jan '15

1 0

k_order_solver
by Johannes Pfeifer 27 Jan '15

27 Jan '15

Hi Houtan, order=3 does not seem to imply k_order_solver in the preprocessor (in contrast to what the manual says). This leads to crashes, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&p=18269 Is this intended or a bug? Best, Johannes

1 0

Status of testsuite in 4.4 branch
by dynbot＠cepremap.org 23 Jan '15

23 Jan '15

2a0aeb6a6f3b3adf2a0a5daf7dced335084c690e Bug correction in splitting the jacobian into blocks: the vector variable_2_block is valid only for endogenous variables. ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 439 | PASS: 437 | FAIL: 0 | XFAIL: 2 | XPASS: 0 ================================ DYNARE MAKE CHECK OCTAVE RESULTS ================================ | TOTAL: 433 | PASS: 431 | FAIL: 0 | XFAIL: 2 | XPASS: 0 A full log can be found on karaba in '/tmp/dynare-4.4-check-tXjp8LPk2p.log'.

1 0

File for #841
by Johannes Pfeifer 22 Jan '15

22 Jan '15

Sending this time to the whole list for archive purposes: Hi Ferhat, could you please have a look at the attached mod-file. It crashes with bytecode because the jacobia_ returned only has 92 columns while without bytecode it has 94. The problem is present in both master and 4.4.3 Best, Johannes -- Johannes Pfeifer Friesenwall 104 50672 Köln Tel.: +49-221-29873852 Mobil.: +49-170-6936820 Germany

1 0

Status of testsuite in master branch
by dynbot＠cepremap.org 22 Jan '15

22 Jan '15

1 0

Status of testsuite in 4.4 branch
by dynbot＠cepremap.org 18 Jan '15

18 Jan '15

843f0f5ce22e0be9c06f24d1d45e0bcbc212771f removing osr_example_objective_correctness.mod from test suite. It relies on parameters (oo_.osr.optim_params) that exist only in master but not in 4.4 ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 439 | PASS: 437 | FAIL: 0 | XFAIL: 2 | XPASS: 0 ================================ DYNARE MAKE CHECK OCTAVE RESULTS ================================ | TOTAL: 433 | PASS: 431 | FAIL: 0 | XFAIL: 2 | XPASS: 0 A full log can be found on karaba in '/tmp/dynare-4.4-check-k6544oK8DG.log'.

1 0

Status of testsuite in master branch
by dynbot＠cepremap.org 18 Jan '15

18 Jan '15

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev January 2015