Dev

dev@dynare.org

3402 discussions

Re: [DynareDev] [Trac] #20: Create new Dynare web site (using Plone)
by Trac Dynare 22 Dec '09

22 Dec '09

#20: Create new Dynare web site (using Plone) ----------------------------+----------------------------------------------- Reporter: sebastien | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: Documentation | Version: Resolution: fixed | Keywords: ----------------------------+----------------------------------------------- Changes (by sebastien): * status: new => closed * resolution: => fixed Comment: The new website is up, and accessible on http://www.dynare.org The old address gives a redirection to the new one. Snapshots are now built on Karaba, and transferred to Kirikou via SSH. There are two flavours of snapshot: source snapshost and Windows binary snapshot. The M2HTML documentation has moved: see the new link in the "Developers' corner" of the Dynare website. -- Ticket URL: <https://www.dynare.org/trac/ticket/20#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] Proposed specification for estimation functions
by G. Perendia 21 Dec '09

21 Dec '09

Hi Sorry for this stream of emails - you may ignore the previous two today (and this one too actually) as I cleared out now how we will link the different priors to the individual parameters and their individual sub-period life-spans in calculation of the posterior, as stated under Parameters and Sub-Samples on the EstimationModule wiki page. Regards George

1 0

[Trac] #67: Bug in gamrnd (prior_draw)
by Trac Dynare 21 Dec '09

21 Dec '09

#67: Bug in gamrnd (prior_draw) --------------------------+------------------------------------------------- Reporter: ratto | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- For some types of gamma samples, like mean=1.5 and std=0.25, which implies a=36, b= 0.0417 the gamrnd dynare routine provides wrong values (too high), always rejected since the values are always above the upper bound. -- Ticket URL: <https://www.dynare.org/trac/ticket/67> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #68: Option stack_solve_algo with values 2, 3 and 4 are not working properly
by Trac Dynare 21 Dec '09

21 Dec '09

#68: Option stack_solve_algo with values 2, 3 and 4 are not working properly --------------------------+------------------------------------------------- Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- See the following files in tests/block_bytecode: fs2000_bicgstab.mod fs2000_gmres.mod fs2000_optpath.mod ramst_a.mod In the first two files, computation succeeds but gives wrong results. In the last two files, MATLAB fails with an error. -- Ticket URL: <https://www.dynare.org/trac/ticket/68> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block)
by Trac Dynare 21 Dec '09

21 Dec '09

#44: The preprocessor can't normalize GIMF model with block+bytecode (but succeeds with only block) --------------------------+------------------------------------------------- Reporter: sebastien | Owner: ferhat Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/44> Dynare <http://www.dynare.org> The Dynare project

1 3

Re: [DynareDev] Proposed specification for estimation functions
by G. Perendia 21 Dec '09

21 Dec '09

PS: or are priors going to be "true" priors, given once for each parameter and valid across all sub-periods? ----- Original Message ----- From: "G. Perendia" <george(a)perendia.orangehome.co.uk> > One issue about the design is, are the priors going to be dependent on the > individual parameters and linked to their lifespans (from start to end of > each period, all the way through), or, after the initial estimation step, > priors will be dependent and related to the common estimation periods - as I > understand it is the latter - and e.g. the posteriors from the previous > (common) sub-sample estimation will become priors for the next - are those > correct views? > > Best regards > > George > > > ----- Original Message ----- > From: "G. Perendia" <george(a)perendia.orangehome.co.uk> > To: <michel.juillard(a)ens.fr> > Cc: <sebastien.villemot(a)ens.fr> > Sent: Saturday, December 12, 2009 11:42 AM > Subject: Re: [DynareDev] Proposed specification for estimation functions > > > > Dear Michel and Sebastien > > > > 1) Perhaps I need to explain better what my line of thought was: > > > > Michel wrote: > > > > > "The estimation algorithm (optimization or MCMC) see all the > > parameters > > > > > for all sub-periods as a single vector. > > > > > > > > > I agree in part. But where is the vector of parameter sub-sample periods > and > > associated priors? > > What I see our Wiki page is describing is what estimation for each period > > (time slot) needs - i.e. just one of the ("longest" common) time-periods > for > > estimation, and the additional info is required to define the start and > the > > end of that period.(which has its start higher/equal than any individual > > parameter's start and its end lower|equal than any individual parameter's > > end in for period slot). > > > > In the (still rough draft of the) model I suggest that information is > mainly > > held (or referred from for the integration as a "view") by the structure > > EstPeriod and all estimation periods in the vector of EstPeriod-s. held in > > the EstimatedParametersDescription together with the time-invariant > > attributes (e.g. IDs..) for integration.. > > > > > > > In updateQHparams(), it is possible to compare the date of the > > relevant > > > > > subperiod with StartPeriod and EndPeriod. I don't think that such > > tests > > > > > would be very costly." > > > > I am also sure it is more efficient to construct those periods once rather > > than repeating time slot/period tests in each call to Likelihood/posterior > > calculation (and there may be 100,000s of those in one estimation) and we > > should use a design that supports that from the start. > > > > Those EstPeriod-s should be constructed at some point (I guess once at a > > start of estimation by EstPeriod constructor ) from the information such > as > > individual parameter start-end periods and the relevant associated priors > > for those periods. That initial info-set is held in the vector of vectors > of > > EstParamSubSampleDescription. > > > > The EstimatedParametersDescription. structure (or class ) integrates all > > that information and makes it available to (friend, for efficiency) class > > LogPosteriorDensity on as needed basis and updates all parameters (inc. H > > and Q) when time slot/period related xparam1 and priors sets are > supplied. > > > > I hope this clarification helps. > > > > > > 2) I however agree that it is often difficult to exchange thoughts over > > email when person-to-person brain-storming discussion is often more > > efficient and contributes to better understanding. If you would like me > to > > come for a meeting in Paris I will and I guess the earlier the better so I > > suggest Monday 21st if that is the earliest suitable for Sebastien and I > can > > stay till Tuesday if you also think that having a spare day for possible > > additional discussion or clarification may be beneficial (or I can just > work > > in the office instead). > > > > Shall I book the tickets for Monday only or Monday and Tuesday (with > > accommodation) then?. > > > > > > PS: I believe that my time spent on the design using the diagramming tool > is > > not wasted since it provides a better overview of the model and it can > also > > produce all the header and .cpp function interface code with the comments > > automatically , thus saving some time on the initial coding side. > > > > Best regards > > George > > > > ----- Original Message ----- From: "G. Perendia" > > <george(a)perendia.orangehome.co.uk> > > > > > > Dear Michel and Sebastien > > > > > > > > I am not sure if it is that simple. > > > > I enclose a draft diagram of basic estimation model with new Estim > > > > parameters description class and its associated (public ? data) > > > structures > > > > that should be created by constructors once and as much as poss. > reused > > > > through repeated calls to CalcPosteriorDensity (e.g. EstPeriods so > that > > we > > > > know how many periods/time slots we need to estimate) ). There is also > > > some > > > > redundancy in the schema so to improve efficiency too. > > > > > > > > I wanted your opinion before I upload it to Wiki page - let me know if > > you > > > > would like more info. > > > > > > > > Best regards > > > > > > > > George > > > > ----- Original Message ----- > > > > From: "Michel Juillard" <michel.juillard(a)ens.fr> > > > > To: "List for Dynare developers" <dev(a)dynare.org> > > > > Sent: Thursday, December 10, 2009 8:11 PM > > > > Subject: Re: [DynareDev] Proposed specification for estimation > functions > > > > > > > > > > > > > Dear George, > > > > > > > > > > I'm not sure that it needs to be that complicated. > > > > > The estimation algorithm (optimization or MCMC) see all the > parameters > > > > > for all sub-periods as a single vector. > > > > > > > > > > In updateQHparams(), it is possible to compare the date of the > > relevant > > > > > subperiod with StartPeriod and EndPeriod. I don't think that such > > tests > > > > > would be very costly. > > > > > > > > > > If I'm wrong and that we need after all the structures that you > > suggest, > > > > > we will add them later. > > > > > > > > > > All the best, > > > > > > > > > > Michel > > > > > > > > > > G. Perendia wrote: > > > > > > Thanks Michel > > > > > > As parameters can have different time slots I think we will need > to > > > add > > > > two > > > > > > structures and: > > > > > > 1 one to )organise data around individual parameters having a > vector > > > of > > > > > > descriptions for each of their time slots, and > > > > > > 2) an additional structure listing all identified longest common > > > periods > > > > > > pointing to each parameter's description for that slot. > > > > > > > > > > > > Thus, > > > > > > re (1) instead of xparam1 being vector of doubles and e.g. > > > start_period > > > > > > vectors having n entries, xpramss1 will be a vector of vectors of > > > > > > structures, and, > > > > > > re (2) timeslots will be a vector of common periods of > > > unpredetermined > > > > > > size, of vectors of length n containing n indices to the relevant > > > > > > parameter's description for that period including its value and > > > priors. > > > > > > > > > > > > Best regards > > > > > > > > > > > > George > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Michel Juillard" <michel.juillard(a)ens.fr> > > > > > > To: "List for Dynare developers" <dev(a)dynare.org> > > > > > > Sent: Thursday, December 10, 2009 10:58 AM > > > > > > Subject: Re: [DynareDev] Proposed specification for estimation > > > functions > > > > > > > > > > > > > > > > > > > > > > > >> Hi George, > > > > > >> > > > > > >> performance improvement was the idea. Lets keep the scalars as > they > > > are > > > > > >> used to distinguish different types of estimation problems. You > can > > > > > >> leave aside the vector of indices until we encounter the need for > > > them. > > > > > >> > > > > > >> Best > > > > > >> > > > > > >> Michel > > > > > >> > > > > > >> G. Perendia wrote: > > > > > >> > > > > > >>> Hi > > > > > >>> > > > > > >>> It seems to me that the following values and vectors described > on > > > the > > > > > >>> > > > > > > (new) > > > > > > > > > > > >>> EstimationModule wiki page are in a way redundant as it looks > like > > > > that > > > > > >>> > > > > > > they > > > > > > > > > > > >>> can > > > > > >>> be derived from the parameter_description type vector. If so, is > > > there > > > > > >>> > > > > > > any > > > > > > > > > > > >>> other > > > > > >>> reason for keeping them explicitly as part of the structure > except > > > > that > > > > > >>> > > > > > > it > > > > > > > > > > > >>> is useful for performance improvement and for easier > understanding > > > > > >>> of the structure? > > > > > >>> > > > > > >>> - nvx integer scalar (number of estimated structural shock > > standard > > > > > >>> deviations). > > > > > >>> -. nvx_id nvx by 1 vector of integers. > > > > > >>> -. nvn integer scalar (number of estimated measurement error > > > standard > > > > > >>> deviations). > > > > > >>> -. nvn_id nvn by 1 vector of integers. > > > > > >>> -. ncx integer scalar (number of estimated structural shock > > > > > >>> > > > > > > correlations). > > > > > > > > > > > >>> -. ncx_id ncx by 1 vector of integers. > > > > > >>> -. ncn integer scalar (number of estimated measurement error > > > > > >>> > > > > > > correlations). > > > > > > > > > > > >>> -. ncn_id ncn by 1 vector of integers. > > > > > >>> -. np integer scalar (number of estimated "deep" parameters). > > > > > >>> -. np_id np by 1 vector of integers. > > > > > >>> > > > > > >>> Best regards > > > > > >>> > > > > > >>> George > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Dev mailing list > > > > > >>> Dev(a)dynare.org > > > > > >>> http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >> _______________________________________________ > > > > > >> Dev mailing list > > > > > >> Dev(a)dynare.org > > > > > >> http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Dev mailing list > > > > > > Dev(a)dynare.org > > > > > > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Dev mailing list > > > > > Dev(a)dynare.org > > > > > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > > > > > >

1 0

Re: [DynareDev] Proposed specification for estimation functions
by G. Perendia 21 Dec '09

21 Dec '09

One issue about the design is, are the priors going to be dependent on the individual parameters and linked to their lifespans (from start to end of each period, all the way through), or, after the initial estimation step, priors will be dependent and related to the common estimation periods - as I understand it is the latter - and e.g. the posteriors from the previous (common) sub-sample estimation will become priors for the next - are those correct views? Best regards George ----- Original Message ----- From: "G. Perendia" <george(a)perendia.orangehome.co.uk> To: <michel.juillard(a)ens.fr> Cc: <sebastien.villemot(a)ens.fr> Sent: Saturday, December 12, 2009 11:42 AM Subject: Re: [DynareDev] Proposed specification for estimation functions > Dear Michel and Sebastien > > 1) Perhaps I need to explain better what my line of thought was: > > Michel wrote: > > > > "The estimation algorithm (optimization or MCMC) see all the > parameters > > > > for all sub-periods as a single vector. > > > > > > I agree in part. But where is the vector of parameter sub-sample periods and > associated priors? > What I see our Wiki page is describing is what estimation for each period > (time slot) needs - i.e. just one of the ("longest" common) time-periods for > estimation, and the additional info is required to define the start and the > end of that period.(which has its start higher/equal than any individual > parameter's start and its end lower|equal than any individual parameter's > end in for period slot). > > In the (still rough draft of the) model I suggest that information is mainly > held (or referred from for the integration as a "view") by the structure > EstPeriod and all estimation periods in the vector of EstPeriod-s. held in > the EstimatedParametersDescription together with the time-invariant > attributes (e.g. IDs..) for integration.. > > > > > In updateQHparams(), it is possible to compare the date of the > relevant > > > > subperiod with StartPeriod and EndPeriod. I don't think that such > tests > > > > would be very costly." > > I am also sure it is more efficient to construct those periods once rather > than repeating time slot/period tests in each call to Likelihood/posterior > calculation (and there may be 100,000s of those in one estimation) and we > should use a design that supports that from the start. > > Those EstPeriod-s should be constructed at some point (I guess once at a > start of estimation by EstPeriod constructor ) from the information such as > individual parameter start-end periods and the relevant associated priors > for those periods. That initial info-set is held in the vector of vectors of > EstParamSubSampleDescription. > > The EstimatedParametersDescription. structure (or class ) integrates all > that information and makes it available to (friend, for efficiency) class > LogPosteriorDensity on as needed basis and updates all parameters (inc. H > and Q) when time slot/period related xparam1 and priors sets are supplied. > > I hope this clarification helps. > > > 2) I however agree that it is often difficult to exchange thoughts over > email when person-to-person brain-storming discussion is often more > efficient and contributes to better understanding. If you would like me to > come for a meeting in Paris I will and I guess the earlier the better so I > suggest Monday 21st if that is the earliest suitable for Sebastien and I can > stay till Tuesday if you also think that having a spare day for possible > additional discussion or clarification may be beneficial (or I can just work > in the office instead). > > Shall I book the tickets for Monday only or Monday and Tuesday (with > accommodation) then?. > > > PS: I believe that my time spent on the design using the diagramming tool is > not wasted since it provides a better overview of the model and it can also > produce all the header and .cpp function interface code with the comments > automatically , thus saving some time on the initial coding side. > > Best regards > George > > ----- Original Message ----- From: "G. Perendia" > <george(a)perendia.orangehome.co.uk> > > > > Dear Michel and Sebastien > > > > > > I am not sure if it is that simple. > > > I enclose a draft diagram of basic estimation model with new Estim > > > parameters description class and its associated (public ? data) > > structures > > > that should be created by constructors once and as much as poss. reused > > > through repeated calls to CalcPosteriorDensity (e.g. EstPeriods so that > we > > > know how many periods/time slots we need to estimate) ). There is also > > some > > > redundancy in the schema so to improve efficiency too. > > > > > > I wanted your opinion before I upload it to Wiki page - let me know if > you > > > would like more info. > > > > > > Best regards > > > > > > George > > > ----- Original Message ----- > > > From: "Michel Juillard" <michel.juillard(a)ens.fr> > > > To: "List for Dynare developers" <dev(a)dynare.org> > > > Sent: Thursday, December 10, 2009 8:11 PM > > > Subject: Re: [DynareDev] Proposed specification for estimation functions > > > > > > > > > > Dear George, > > > > > > > > I'm not sure that it needs to be that complicated. > > > > The estimation algorithm (optimization or MCMC) see all the parameters > > > > for all sub-periods as a single vector. > > > > > > > > In updateQHparams(), it is possible to compare the date of the > relevant > > > > subperiod with StartPeriod and EndPeriod. I don't think that such > tests > > > > would be very costly. > > > > > > > > If I'm wrong and that we need after all the structures that you > suggest, > > > > we will add them later. > > > > > > > > All the best, > > > > > > > > Michel > > > > > > > > G. Perendia wrote: > > > > > Thanks Michel > > > > > As parameters can have different time slots I think we will need to > > add > > > two > > > > > structures and: > > > > > 1 one to )organise data around individual parameters having a vector > > of > > > > > descriptions for each of their time slots, and > > > > > 2) an additional structure listing all identified longest common > > periods > > > > > pointing to each parameter's description for that slot. > > > > > > > > > > Thus, > > > > > re (1) instead of xparam1 being vector of doubles and e.g. > > start_period > > > > > vectors having n entries, xpramss1 will be a vector of vectors of > > > > > structures, and, > > > > > re (2) timeslots will be a vector of common periods of > > unpredetermined > > > > > size, of vectors of length n containing n indices to the relevant > > > > > parameter's description for that period including its value and > > priors. > > > > > > > > > > Best regards > > > > > > > > > > George > > > > > > > > > > ----- Original Message ----- > > > > > From: "Michel Juillard" <michel.juillard(a)ens.fr> > > > > > To: "List for Dynare developers" <dev(a)dynare.org> > > > > > Sent: Thursday, December 10, 2009 10:58 AM > > > > > Subject: Re: [DynareDev] Proposed specification for estimation > > functions > > > > > > > > > > > > > > > > > > > >> Hi George, > > > > >> > > > > >> performance improvement was the idea. Lets keep the scalars as they > > are > > > > >> used to distinguish different types of estimation problems. You can > > > > >> leave aside the vector of indices until we encounter the need for > > them. > > > > >> > > > > >> Best > > > > >> > > > > >> Michel > > > > >> > > > > >> G. Perendia wrote: > > > > >> > > > > >>> Hi > > > > >>> > > > > >>> It seems to me that the following values and vectors described on > > the > > > > >>> > > > > > (new) > > > > > > > > > >>> EstimationModule wiki page are in a way redundant as it looks like > > > that > > > > >>> > > > > > they > > > > > > > > > >>> can > > > > >>> be derived from the parameter_description type vector. If so, is > > there > > > > >>> > > > > > any > > > > > > > > > >>> other > > > > >>> reason for keeping them explicitly as part of the structure except > > > that > > > > >>> > > > > > it > > > > > > > > > >>> is useful for performance improvement and for easier understanding > > > > >>> of the structure? > > > > >>> > > > > >>> - nvx integer scalar (number of estimated structural shock > standard > > > > >>> deviations). > > > > >>> -. nvx_id nvx by 1 vector of integers. > > > > >>> -. nvn integer scalar (number of estimated measurement error > > standard > > > > >>> deviations). > > > > >>> -. nvn_id nvn by 1 vector of integers. > > > > >>> -. ncx integer scalar (number of estimated structural shock > > > > >>> > > > > > correlations). > > > > > > > > > >>> -. ncx_id ncx by 1 vector of integers. > > > > >>> -. ncn integer scalar (number of estimated measurement error > > > > >>> > > > > > correlations). > > > > > > > > > >>> -. ncn_id ncn by 1 vector of integers. > > > > >>> -. np integer scalar (number of estimated "deep" parameters). > > > > >>> -. np_id np by 1 vector of integers. > > > > >>> > > > > >>> Best regards > > > > >>> > > > > >>> George > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Dev mailing list > > > > >>> Dev(a)dynare.org > > > > >>> http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > >>> > > > > >>> > > > > >>> > > > > >> _______________________________________________ > > > > >> Dev mailing list > > > > >> Dev(a)dynare.org > > > > >> http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Dev mailing list > > > > > Dev(a)dynare.org > > > > > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Dev mailing list > > > > Dev(a)dynare.org > > > > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > > > >

1 0

[Trac] #48: Incorrect treatment of log-linear transformation for purely backward looking models
by Trac Dynare 19 Dec '09

19 Dec '09

#48: Incorrect treatment of log-linear transformation for purely backward looking models --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- In dr1.m, log-linear test and the log-linear transformation of the model ghx and ghu matrices at line 449 are not reached for a purely backward looking model, because of a return statement at line 266 -- Ticket URL: <https://www.dynare.org/trac/ticket/48> Dynare <http://www.dynare.org> The Dynare project

1 1

(no subject)
by Tao Zha 19 Dec '09

19 Dec '09

Dear Michel: Attached is my revised documentation for the Dynare interface of SWZ. Feel free to expand or modify it. Two more things. 1) The request for the Atlanta Fed's commitment to Dynare's membership is moving forward. I'm awaiting for an official answer from the financial planning department here. 2) Perhaps we can arrange Houton to come to the Atlanta fed for a few things to wrap up the SWZ stuff. January and February can be busy for me as I have to help recruiting for both institutions (Fed and Emory). I wonder if some time in March is good for Houton. If not, we can certainly have Houton visiting earlier. I'm just stating my preference and do not want to rule out any particular month. Hope all is well with you and your family. Merry Christmas, Tao

1 0

[Trac] #70: USE_DLL option affected by the timestamp directory bug of Octave 3.2
by Trac Dynare 18 Dec '09

18 Dec '09

#70: USE_DLL option affected by the timestamp directory bug of Octave 3.2 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/70> Dynare <http://www.dynare.org> The Dynare project

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev