Hi there,
the guiding principle should be to do the integration right from the start and
commit the necessary resources rather than having to do it over later.
1) to you have a write-up with the algebra that needs to be performed for
partial information inside Dynare?
2) we have first to decide whether it is best to treat expectations as different
(auxiliary) endogenous variables or to define a 4th type.
- Currently, in full information, if we want E_{t-1} y_t, one needs to create an
auxiliary variable and an auxiliary equation
ey = y(+1)
and use ey(-1) instead of E_{t-1} y_t.
If we are to provide an explicit operator E{i}{y}, the preprocessor would need
to create the auxiliary variable, add the equation to the model, and perform
the substitution as needed.
We would need to keep a table of these auxiliary variables, but it doesn't seem
necessary or desirable to create a 4th type of variable because the rules for
output would be the same as for regular endogenous variables
[Currently, I have also doubt about the distinction endogenous/exogenous, but
this is another story...]
Are there reasons to believe this would be different with partial information?
Best
Michel
Quoting "G. Perendia" <george(a)perendia.orangehome.co.uk>:
> Dear Joe
>
> I have been thinking about the integration of the Partial information and
> current expectations into Dynare as you asked me to and I have some ideas but
> no easy solutions.
>
> As I mentioned, a shortcut solution may require additional proxy variables
> for contemporary expectations such as ETYT_t = Et[y_t].
>
> I expect an additional expectation error equations will be required that
> should avoid determinacy issues with the additional variable and the possible
> problems when solved, e,g, for steady state, poss on the lines of:
>
> y_t = ETYT_t + e_t
>
> Using then an additional structure (e.g. set inside the M_ or options_
> structures) that is mapping expectations to their bases on the lines of:
>
> ['YTT' 'Y_t'; ......]
>
> the Part info solver will be able to identify which of the relations are
> "dummy" and then transform and solve the model for decision rule using its
> own solver.
>
> This solution however may become rather tedious to model from the user
> perspective, that is, if at all plausible - so, please let me know what you
> think. It will also require some parsing of the model within PI module to
> map-in expectations.
>
>
> Alternatively, the proper integration would require changing start-to-end
> Dynare pipeline, from the parser/prerpocessor to KF estimation. It may then
> require adding 4th type of variable: expectation in addition to the existing:
> predetermined, forward and static variables, and, thus, changes to the
> numerous internal structures and functions.
>
> This will, however, probably introduce an additional burden on the design and
> development resources, rather more than initially envisaged.
>
>
> Best regards
>
> George
> Mob. +44(0)7951415480
> artilogica(a)btconnect.com
>
--
