December 2009 - Dev - dynare.org

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

[Trac] #71: rplot command fails on model with no lags
by Trac Dynare 18 Dec '09

18 Dec '09

#71: rplot command fails on model with no lags --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/71> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] 4.1 branched out
by Sébastien Villemot 18 Dec '09

18 Dec '09

Le jeudi 17 décembre 2009 à 23:42 +0000, G. Perendia a écrit : > Running make with new trunk code I am getting an error when it reach > building the k_order_perturbation: > > make[2]: *** No rule to make target > '../../../sources/k_order_perturbation/k_order_perturbation.cpp' needed by > 'k_order_perturbation.o' Stop. > > although the .cpp and .h files in sources/k_order_perturbation have been > replaced by the new .cc and .hh files. You need to run "make distclean", then re-configure, and re-compile. It seems that automake doesn't handle well such renaming of source files... Best -- Sébastien Villemot

1 0

4.1 branched out
by Sébastien Villemot 16 Dec '09

16 Dec '09

Hi, After having reindented and beautified all Dynare code, I created the branch for Dynare 4.1. This marks the beginning of the test phase for Dynare 4.1, and the opening of a new development cycle (until Dynare 4.2 is released). You are therefore free to add new features to the trunk or to start deep refactoring. Please test the 4.1 branch. If you spot bugs, please fix them in the trunk, and I will merge them in the branch. There are still 5 open bugs against Dynare 4.1 in Trac, we need to fix them before we can release Dynare 4.1.0. Best, -- Sébastien Villemot

1 0

Re: [DynareDev] [Trac] #16: Reindent all source code (C++, M-files)
by Trac Dynare 16 Dec '09

16 Dec '09

#16: Reindent all source code (C++, M-files) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: enhancement | Status: closed Priority: trivial | Milestone: 4.1 Component: Core M-files | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed -- Ticket URL: <https://www.dynare.org/trac/ticket/16#comment:3> Dynare <http://www.dynare.org> The Dynare project

1 0

[Trac] #66: Document the fast deterministic simulations in the reference manual
by Trac Dynare 16 Dec '09

16 Dec '09

#66: Document the fast deterministic simulations in the reference manual ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: feature | Status: new Priority: major | Milestone: 4.1 Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ At least we should incoporate the new options described on: http://www.dynare.org/DynareWiki/FastDeterministicSimulationAndSteadyStateC… -- Ticket URL: <https://www.dynare.org/trac/ticket/66> Dynare <http://www.dynare.org> The Dynare project

1 1