Re: [DynareDev] Proposed specification for estimation functions - Dev

21 Dec 2009

      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

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.

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