Dev

dev@dynare.org

3402 discussions

Status of testsuite in master branch
by Dynare Robot 15 Mar '15

15 Mar '15

1 0

Status of testsuite in master branch
by Dynare Robot 14 Mar '15

14 Mar '15

1 0

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

Status of testsuite in master branch
by Dynare Robot 12 Mar '15

12 Mar '15

1 0

Status of testsuite in 4.4 branch
by Dynare Robot 10 Mar '15

10 Mar '15

82d43818f5f276fb066bc0b45c31037a378d92f2 Fix issue with purely forward deterministic models with lags on exogenous. ================================ 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-T1hOkh4LFs.log'.

1 0

Status of testsuite in master branch
by Dynare Robot 10 Mar '15

10 Mar '15

1 0

Status of testsuite in master branch
by Dynare Robot 07 Mar '15

07 Mar '15

1 0

Status of testsuite in 4.4 branch
by Dynare Robot 07 Mar '15

07 Mar '15

c8221cac229e8538005a21a706c4e342d082c960 preprocessor: bug fix; warning should be issued if there is at least one unused exo not more than one ================================ 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-bI6RfZpXGa.log'.

1 0

Status of testsuite in master branch
by Dynare Robot 06 Mar '15

06 Mar '15

1 0

Observation trends and prefiltering
by Johannes Pfeifer 04 Mar '15

04 Mar '15

Dear all, I finally pushed the commits fixing the host of bugs related to trends, prefiltering, first_obs, and loglinear to https://github.com/DynareTeam/dynare/pull/852. Could you please have a look at them and provide feedback. I would be grateful if this pull request could be merged before any further large changes to the estimation interface. Integreting this was a hassle and I already had to change the code twice before due to larger updates. Thus, I would like to avoid merge conflicts as is the case for many open pull requests. Given the by now rather large difference between the unstable and 4.4 branch, I would be very reluctant to port these fixes to 4.4. What is the plan for the next releases? Additional points: @Michel and @Stephane:Could you please check whether the saving of results conducted in write_smoother_results.m is as desired and discussed in http://www.dynare.org/DynareWiki/OutputVariables. The most controversial issue from my point of view is that when using the loglinear option, the results of the smoother are saved for the logged variables, i.e. I opted not to invert the logging. The reason for this is that I did not envision cases where someone actually want to estimate a model in percentage deviations but wants to compare the results to unlogged data. If you think this should be different, I can easily change it. I will also provide documentation for the changes once we have agreed the design choices are OK. @Marco: I haven't touched any of the identification routines, but the option to estimate trend coefficients most probably has consequences for that part of the code, too. Best, Johannes

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev