Dev May 2013

dev@dynare.org

3 participants
61 discussions

Status of testsuite in master branch
by sebastien＠dynare.org 05 May '13

05 May '13

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 04 May '13

04 May '13

9a401db62cc54cbac004896f8c6d7f0613127d9a Merge pull request #383 from rattoma/4.3 *************************************** * DYNARE TEST RESULTS * * for make check-matlab * *************************************** 193 tests PASSED out of 193 tests run *************************************** *************************************** * DYNARE TEST RESULTS * * for make check-octave * *************************************** 191 tests PASSED out of 191 tests run *************************************** A full log can be found on karaba in '/tmp/dynare-4.3-check-Tkmw9cFeFP.log'.

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 04 May '13

04 May '13

1 0

Dynare for Julia
by Sébastien Villemot 03 May '13

03 May '13

Hi, Just for your information, I have started a Dynare package for Julia. Note that this is not a binding to the MATLAB/Octave code, but rather a (very preliminary and incomplete) rewrite from scratch. https://github.com/DynareTeam/Dynare.jl For the moment, this is only thought as a prototype for exploratory purposes. It only does steady state computation and first order decision rules. One interesting point is that it is 100% pure Julia code: I could write the equivalent of the preprocessor (symbolic derivatives) and of mjdgges (MEX for QZ decomposition) entirely in Julia code, without the need for C/C++. Also note that the code is very small (less than 800 lines, including newlines). -- Sébastien Villemot Researcher in Economics Dynare developer http://www.dynare.org/sebastien

1 0

info(2) usage
by Michel Juillard 03 May '13

03 May '13

We need to decide if we want to reserve the usage of info(2) for penalty. When we use a Newton type numerical optimizer to find the mode of the posterior or of the likelihood or when we are searching for optimal parameters in OSR, using stiff penalties creates "cliffs" that the optimizer has difficulties to overcome. To alleviate the problem, we have tried, whenever possible, to compute penalties commensurate with the violation (sum of square residuals when one can't find the steady state, norm of eigenvalues on the "wrong" side of one for BK violations, ...). These endogenous penalties have been put in info(2). Of course, it is not always possible to compute a commensurate penalty and we still have a few cliffs. However, we have also used info(2), in a few cases (info(1)==8) to provide additional details about the nature of the error. I think that we should refrain from using info(2) that way and probably change the handling of the cases that do that, because it leads to confusions. But, I would like to have your advice on that. It may be the occasion of having a more general discussion on the handling of errors in Dynare. If I remember correclty, some of you would prefer using exceptions. We could also decide that we want to redesign the handling of errors in Dynare. Please, tell me what you think. Best -- Michel Juillard

2 1

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 03 May '13

03 May '13

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 03 May '13

03 May '13

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 02 May '13

02 May '13

1 0

Status of testsuite in master branch
by sebastien＠dynare.org 02 May '13

02 May '13

1 0

Status of testsuite in 4.3 branch
by sebastien＠dynare.org 01 May '13

01 May '13

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev May 2013