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@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@btconnect.com