Re: [DynareDev] Proposed specification for estimation functions
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@perendia.orangehome.co.uk> To: <michel.juillard@ens.fr> Cc: <sebastien.villemot@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@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@ens.fr> To: "List for Dynare developers" <dev@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@ens.fr> To: "List for Dynare developers" <dev@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@dynare.org > http://www.dynare.org/cgi-bin/mailman/listinfo/dev > > > _______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
participants (1)
-
G. Perendia