Dev September 2008

dev@dynare.org

6 participants
16 discussions

Broken functions
by Sébastien Villemot 10 Sep '08

10 Sep '08

The following functions are implemented in the preprocessor, but are currently broken: * dsample: the preprocessor sets options_.dsample when encountering this command, but this option is never used in the Matlab code (just initialized in global_initialization); however, there exists a dsample.m which sets options_.smpl. I suppose I should fix this by asking the preprocessor to call dsample.m (or maybe even incorporate the content of dsample.m into the preprocessor). Am I right ? * calib and calib_var: it is clear that the Matlab files (calib.m, calib_obj.m and calib_obj2.m) corresponding to these functions are currently broken (the function prototypes contain global variables, which makes no sense...). What should we do about these? * model_comparison: the Matlab file corresponding to this preprocessor command is actually missing (it has not been ported from v3). Stéphane is going to look at this. Best Sébastien

1 0

/branches/4.0/locked ?
by Stéphane Adjemian 08 Sep '08

08 Sep '08

Hi all, Did someone locked the svn repository (/branches/4.0) ? I cannot commit... Best, Stéphane. Stéphane Adjemian Université du Maine, GAINS & CEPREMAP http://www.cepremap.cnrs.fr/~adjemian

3 3

changes in Dynare v4
by Michel Juillard 06 Sep '08

06 Sep '08

Hi everybody, I just realized that with all the changes that we made to the function names (distributions) and the calling sequences, we broke all code written by Dynare users and using Dynare internals. We need to document these changes quickly on DynareWiki. We need to write a tool (perl, python, ...) that -compares two dynare versions (only /matlab/ and subdirectories) -which *.m f ile were added/deleted -extracts the function ..... line, compares the argument lists and reports differences. Who can start working on it? Best Michel

3 3

freezing version 4.0.0
by Michel Juillard 05 Sep '08

05 Sep '08

Hi everybody, on SVN, I have created branches/4.0 to freeze version 4.0.0 Most changes necessary to release version 4.0.0 have been done. There are a few keywords/options that need to be added to the preprocessor and more tests need to be done. Please keep adding new features to the trunk (don't change anything to your SVN setup). If you want to test version 4.0.0, please check out branches/4.0 in a separate working directory, then commit only bug corrections from this working directory. Best, Michel -------- Original Message -------- Subject: Re: SVN Date: Tue, 08 Jul 2008 17:40:56 +0200 From: Sébastien Villemot <sebastien.villemot(a)ens.fr> To: stephane.adjemian(a)ens.fr CC: Michel Juillard <michel.juillard(a)ens.fr>, George Perendia <artilogica(a)btconnect.com> References: <487370EC.4010500(a)ens.fr> <200807081638.05166.stephane.adjemian(a)ens.fr> <20080708165802.17365ydzqi1sg8sg(a)www.zelya.net> <200807081712.03561.stephane.adjemian(a)ens.fr> Here is the timeline: * we finish Dynare 4.0.0 in the trunk (dynare_v4/) * when we're done, we copy dynare_v4/ to branches/4.0 and tags/4.0.0 * we fix bugs in branches/4.0, creating new releases when we feel the need (creating a release involves copying branches/4.0 to tags/4.0.x where x is the minor release number) * meanwhile, we add new features or restructure the code in the trunk (dynare_v4/). Also note that many bug fixes done on the 4.0 branch will also apply to the trunk * when we think we can make a new major release (for example when we've completed September 30 goals), we release 4.1.0 by copying dynare_v4/ to branches/4.1 and tags/4.1.0 * we continue the parallel development of the trunk, the 4.1 branch, and maybe the 4.0 branch (or we can decide to drop the 4.0 branch at that point) Sébastien "Stéphane Adjemian" <stephane.adjemian(a)ens.fr> a écrit : > So we use branches/4.0 to fix the bugs and use dynare_v4 to develop > dynare. Am > I right ? But what is the purpose of branches/4.1 (before the release of > dynare 4.1.0) ? > > Stéphane. > > > Le Tuesday 08 July 2008 16:58:02, vous avez écrit : >> Under our current tree layout: >> * dynare_v4/ is the trunk >> * branches/ is for branches (for example branches/4.0/ or branches/4.1/) >> * tags/ is for releases (tags/4.0.0, tags/4.0.1, ...) >> >> Sébastien >> >> "Stéphane Adjemian" <stephane.adjemian(a)ens.fr> a écrit : >> > I also agree with Sébastien suggestion (if the trunk is the current >> > dynare_v4 directory under svn). >> > >> > Stéphane. >> > >> > Le Tuesday 08 July 2008 16:29:36 G. Perendia, vous avez écrit : >> >> I support Sebastian's suggestion which, as he pointed out, is in line >> >> with the SW industry standard practices. We may also have the >> >> "traditional" "alpha" and "beta" releases (but that is just a matter of >> >> naming the X.0.0 and X.0.1 releases respectively). >> >> >> >> Best regards >> >> >> >> George >> >> Mob. +44(0)7951415480 >> >> artilogica(a)btconnect.com >> >> >> >> ----- Original Message ----- >> >> From: "Sébastien Villemot" <sebastien.villemot(a)ens.fr> >> >> To: "Michel Juillard" <michel.juillard(a)ens.fr> >> >> Cc: "George Perendia" <artilogica(a)btconnect.com>; "StéphaneAdjemian" >> >> <stephane.adjemian(a)gmail.com> >> >> Sent: Tuesday, July 08, 2008 3:12 PM >> >> Subject: Re: SVN >> >> >> >> >> >> Concerning Dynare release schedule, one option would be the following: >> >> >> >> * finish Dynare 4.0, and release version 4.0.0 >> >> * create a 4.0 branch in the SVN, used only for bugfixes; in other >> >> words, versions 4.0.1, 4.0.2... would only incoporate bug fixes since >> >> 4.0.0, but no new feature nor code restructuring >> >> * add new features or code restructurings in the trunk; the trunk will >> >> later become the 4.1 branch (maybe for the September 30 deadline) >> >> * and so on at each major release/deadline... >> >> >> >> This model of development is used in many softwares. Its main interest >> >> is that it produces very stable software at the end of a development >> >> branch, since no new feature can destabilize the code along a branch. >> >> On the other hand, it involves some overhead related to the >> >> simultaneous management of a branch and a trunk (a bugfix needs often >> >> to be applied to both). >> >> >> >> Do you think it is a sensible development model for Dynare? >> >> >> >> Best >> >> >> >> Sébastien >> >> >> >> "Michel Juillard" <michel.juillard(a)ens.fr> a écrit : >> >> > I have added 'george' as username authorized to commit on the SVN >> >> > archive. The password is as mentioned at the Summer School. >> >> > George will also get the email messages after each commit. >> >> > >> >> > Stephane, I checked that these messages go for you at >> >> > stephane.adjemian(a)ens.fr. Is it what you want? >> >> > >> >> > best >> >> > >> >> > Michel > > >

2 2

options_.replic
by Stéphane Adjemian 04 Sep '08

04 Sep '08

Hi all, We have a problem with options_.replic which is used for three different purposes (number of prior simulations, irfs with a second order approximation and repeated stochastic simulations). In global_initialization.m this variable is defined twice! We have: * options_.replic =1 for prior simulations (?) , and after * options_.replic = 50 for irfs with a second order approximation ... So that the default value is 50. When the user asks for a stochastic simulation with a second order approximation, dynare simulates 50 times the model and displays the results associated to the last simulated time series. Shouldn't we create new fields in options_ ? If so, how should I call them (for the prior sampler and for the repeated stochastic simulations) ? Something will have to be fixed also in the preprocessor. Best, Stéphane. Stéphane Adjemian Université du Maine, GAINS & CEPREMAP.

2 1

AIM for Dynare copyrights
by Sébastien Villemot 02 Sep '08

02 Sep '08

Hi George, I intend to give proper license headers to all files under the AIM/ subdirectory (since Gary has said that their are in the public domain). By comparing to Gary's original files, I noticed that 3 files of the Dynare distribution are not in the ZIP file downloadable from the Fed's website: * SPEigQZ.m * SPQZ.m * SPSparse.m The first two seem to be never used in the code, while the third one is simply a call to sparse() and therefore could easily be removed. Is there any good reason to keep these files, and, if yes, who owns the copyright? Best Sébastien

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev September 2008