Dev March 2014

dev@dynare.org

2 participants
38 discussions

Status of testsuite in 4.4 branch
by sebastien＠dynare.org 12 Mar '14

12 Mar '14

99fca41c676f9cd5c760c80dbb2601ebc884a463 Implement cloneDynamic() for {First,Second}DerivExternalFunction. ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 423 | PASS: 421 | FAIL: 0 | XFAIL: 2 | XPASS: 0 ================================ DYNARE MAKE CHECK OCTAVE RESULTS ================================ | TOTAL: 421 | PASS: 419 | FAIL: 0 | XFAIL: 2 | XPASS: 0 A full log can be found on karaba in '/tmp/dynare-4.4-check-zbOS6EZtvX.log'.

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 12 Mar '14

12 Mar '14

da615507f486cb25eb539cbbbe71dc9f7d34fe67 Cosmetic renaming for consistency between DataTree method names. ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 435 | PASS: 433 | 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-master-check-frnUzGVdJh.log'.

1 0

Status of testsuite in 4.4 branch
by sebastien＠dynare.org 11 Mar '14

11 Mar '14

e9a52c3244a9255e179a4e9f6c0d8f8020d9891a Ensure that -lpthread is statically linked under MinGW. ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 423 | PASS: 421 | FAIL: 0 | XFAIL: 2 | XPASS: 0 ================================ DYNARE MAKE CHECK OCTAVE RESULTS ================================ | TOTAL: 421 | PASS: 419 | FAIL: 0 | XFAIL: 2 | XPASS: 0 A full log can be found on karaba in '/tmp/dynare-4.4-check-QVQvCjcmXO.log'.

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 11 Mar '14

11 Mar '14

1 0

Trust-region nonlinear solver
by Sébastien Villemot 10 Mar '14

10 Mar '14

Hi, I just added a new nonlinear solver for the steady command: it is a trust-region solver, available under solve_algo=4 (it replaces the old value of that option, which was a Newton without the correction for singular Jacobian; I had added that variant a long time ago, and it was neither really useful nor theoretically grounded). The implementation of the solver is essentially the fsolve.m from Octave, that I have adapted for MATLAB compatibility and that I have also slightly simplified. I am wondering whether we may want to use this new solver as the default, since trust-region algorithms are nowadays considered to be the state of the art for solving systems of nonlinear equations. Said otherwise, should we modify the default to be solve_algo=4 instead of solve_algo=2 ? Since I have not thoroughly tested the new solver, a first step would probably to test it on various relevant examples. Best, -- Sébastien Villemot Researcher in Economics Dynare developer http://www.dynare.org/sebastien

4 5

Status of testsuite in master branch
by sebastien＠dynare.org 10 Mar '14

10 Mar '14

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 08 Mar '14

08 Mar '14

f58a72c54df3219151fb15cac2ee4b6cc83fb5da Merge pull request #629 from JohannesPfeifer/mh_conf_sig ================================ DYNARE MAKE CHECK MATLAB RESULTS ================================ | TOTAL: 433 | PASS: 431 | FAIL: 0 | XFAIL: 2 | XPASS: 0 ================================ DYNARE MAKE CHECK OCTAVE RESULTS ================================ | TOTAL: 431 | PASS: 429 | FAIL: 0 | XFAIL: 2 | XPASS: 0 A full log can be found on karaba in '/tmp/dynare-master-check-iiYhQjbNuF.log'.

1 0

Re: [DynareDev] [DynareWiki] Update of "DeterministicSimulationBlocks" by JohannesPfeifer
by Sébastien Villemot 07 Mar '14

07 Mar '14

Le lundi 03 mars 2014 à 13:30 +0000, DynareWiki a écrit : > The "DeterministicSimulationBlocks" page has been changed by JohannesPfeifer: Thanks Johannes for the analysis of the problems with the current interface. I think this is very useful. If we want to tackle this issue, the biggest challenge of course is to maintain backward compatibility. For that reason, I think it is not possible to change the semantics of existing blocks. I think the most realistic plan would therefore consist in introducing new syntaxes that would co-exist with the old ones. Then we would recommend the use of the new syntaxes, and deprecate the old ones by issuing warnings when they are used. And finally, after a few major releases, we could drop the old syntaxes. If everyone agrees with this approach, the next step would therefore to suggest some new syntaxes and precisely describe their semantics. -- Sébastien Villemot Researcher in Economics Dynare developer http://www.dynare.org/sebastien

1 0

OSR
by Johannes Pfeifer 07 Mar '14

07 Mar '14

Dear all, is there a particular reason for not saving the results of osr (stored in osr_res during the run of osr.m) into oo_? If not, I would suggest to add a subfield osr to oo_ in order to store oo_.osr.optim_params and oo_.osr.objective_function My current reading is that those values are printed, but are not easily accessible. Best, Johannes

2 2

metropolis_draw
by Johannes Pfeifer 06 Mar '14

06 Mar '14

Dear Stephane, could you please take a look at metropolis_draw.m It contains a check options_.sub_draws>NumberOfDraws that I think is wrong. NumberOfDraws relates only to the draws within each block (the maximum index allowed for each chain). But sub_draws are the draws across all chains. My hunch is that the check should be something like options_.sub_draws>NumberOfDraws*mh_nblck Best, Johannes -------- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil: +49-(0)170-6936820 jpfeifer(a)gmx.de

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev March 2014