Hi all,
I have made an important change in the preprocessor, which should fix an important bug that Michel has discovered. It turns out that Dynare gives a wrong result for stochastic approximation at order 2 for models with leads of 2 or more.
In order to fix that bug, the preprocessor now removes all leads and lags >=2 for a stochastic model. It does so by creating auxiliary variables and equations, so that the model has only one lead and one lag. This is the strategy used by Dynare++, and it is the easiest way to fix that bug.
So don't be surprised if Dynare reports more equations than you declared, and if some variables called "AUXLEAD..." and "AUXLAG..." appear. You can examine the result of the transformation by using the "write_latex_dynamic_model" command (see http://www.dynare.org/DynareWiki/ModelLatexOutput )
The bug should now be fixed (although I now have a crash on GIMF in dr1.m). What remains to be done is the adaptation of the output routines, so that the output remains the same than before (instead of having the auxiliary variables in it).
Houtan: for the auxiliary variables related to the expectation operator, you can reuse the framework that I have setup. * in SymbolTable.hh, add a new enum to aux_var_t, a new method for adding your type of aux var, and if needed new fields to AuxVarInfo * add a new method to class DynamicModel (similar to those for substituting leads and lags) * call that new method from ModFile::transformPass(), *before* the methods substituting leads and lags * for the initialization of new aux variables (since they are not declared in the "initval" block, the preprocessor needs to give an initial value to them): you need to add your new auxiliary equations to ModelTree::aux_equations; this should suffice, the mechanism that I have setup in DynamicModel::fillEvalContext() and StaticModel::writeAuxInitval() should take care of it
Best,
Thanks a lot Sebastien,
I some questions, mostly related to analytic derivatives of the model w.r.t. parameters: how does this affect the analytic derivatives w.r.t. parameters?
Morever, do dr.ghx and dr.ghu now include the auxiliary variables lines (which up to now had to be reconstructed in kalman_transion_matrix)?
Finally, all info in dr and M_ will be in a way that only one lead an lag is present (kstate, lead_lag_incidence, ...)?
Many thanks again for your help best wishes Marco
Sébastien Villemot wrote:
Hi all,
I have made an important change in the preprocessor, which should fix an important bug that Michel has discovered. It turns out that Dynare gives a wrong result for stochastic approximation at order 2 for models with leads of 2 or more.
In order to fix that bug, the preprocessor now removes all leads and lags >=2 for a stochastic model. It does so by creating auxiliary variables and equations, so that the model has only one lead and one lag. This is the strategy used by Dynare++, and it is the easiest way to fix that bug.
So don't be surprised if Dynare reports more equations than you declared, and if some variables called "AUXLEAD..." and "AUXLAG..." appear. You can examine the result of the transformation by using the "write_latex_dynamic_model" command (see http://www.dynare.org/DynareWiki/ModelLatexOutput )
The bug should now be fixed (although I now have a crash on GIMF in dr1.m). What remains to be done is the adaptation of the output routines, so that the output remains the same than before (instead of having the auxiliary variables in it).
Houtan: for the auxiliary variables related to the expectation operator, you can reuse the framework that I have setup.
- in SymbolTable.hh, add a new enum to aux_var_t, a new method for
adding your type of aux var, and if needed new fields to AuxVarInfo
- add a new method to class DynamicModel (similar to those for
substituting leads and lags)
- call that new method from ModFile::transformPass(), *before* the
methods substituting leads and lags
- for the initialization of new aux variables (since they are not
declared in the "initval" block, the preprocessor needs to give an initial value to them): you need to add your new auxiliary equations to ModelTree::aux_equations; this should suffice, the mechanism that I have setup in DynamicModel::fillEvalContext() and StaticModel::writeAuxInitval() should take care of it
Best,
Le mercredi 30 septembre 2009 à 17:58 +0200, Marco Ratto a écrit :
I some questions, mostly related to analytic derivatives of the model w.r.t. parameters: how does this affect the analytic derivatives w.r.t. parameters?
The idea is that the preprocessor transforms a model with leads and lags
=2 in a model with one lead and one lag, in a way which is meant to be
completely transparent to the MATLAB routines. For example, the structure M_.endo_names contains the new auxiliary variables. The output of the transformation is still a valid Dynare model; the only difference is that it has more equations/endogenous than what the user declared.
I think this doesn't change much, except that you will also have the derivatives of equations which were added during the transformation.
Morever, do dr.ghx and dr.ghu now include the auxiliary variables lines (which up to now had to be reconstructed in kalman_transion_matrix)?
Yes.
Finally, all info in dr and M_ will be in a way that only one lead an lag is present (kstate, lead_lag_incidence, ...)?
Yes.
Many thanks for the clarifications. I think this is great advance for the transparency of model structures into dynare! best Marco
Sébastien Villemot wrote:
Le mercredi 30 septembre 2009 à 17:58 +0200, Marco Ratto a écrit :
I some questions, mostly related to analytic derivatives of the model w.r.t. parameters: how does this affect the analytic derivatives w.r.t. parameters?
The idea is that the preprocessor transforms a model with leads and lags
=2 in a model with one lead and one lag, in a way which is meant to be
completely transparent to the MATLAB routines. For example, the structure M_.endo_names contains the new auxiliary variables. The output of the transformation is still a valid Dynare model; the only difference is that it has more equations/endogenous than what the user declared.
I think this doesn't change much, except that you will also have the derivatives of equations which were added during the transformation.
Morever, do dr.ghx and dr.ghu now include the auxiliary variables lines (which up to now had to be reconstructed in kalman_transion_matrix)?
Yes.
Finally, all info in dr and M_ will be in a way that only one lead an lag is present (kstate, lead_lag_incidence, ...)?
Yes.
Hello,
I just would like to check two things regarding the implementation of the Expectation operator:
1) Where should I check that arg1 is numeric in "EXPECTATION(arg1)(arg2)": during parsing, within the checkPass(), or during the transformPass() while dealing with the expectation operator?
2) I also want to make sure that, after creating auxiliary variables for every instance of oExpectation, I should erase the associated BinaryOpNode.
This should be done in the next couple of days.
Thanks, Houtan
2009/9/30 Sébastien Villemot sebastien.villemot@ens.fr
Hi all,
I have made an important change in the preprocessor, which should fix an important bug that Michel has discovered. It turns out that Dynare gives a wrong result for stochastic approximation at order 2 for models with leads of 2 or more.
In order to fix that bug, the preprocessor now removes all leads and lags >=2 for a stochastic model. It does so by creating auxiliary variables and equations, so that the model has only one lead and one lag. This is the strategy used by Dynare++, and it is the easiest way to fix that bug.
So don't be surprised if Dynare reports more equations than you declared, and if some variables called "AUXLEAD..." and "AUXLAG..." appear. You can examine the result of the transformation by using the "write_latex_dynamic_model" command (see http://www.dynare.org/DynareWiki/ModelLatexOutput )
The bug should now be fixed (although I now have a crash on GIMF in dr1.m). What remains to be done is the adaptation of the output routines, so that the output remains the same than before (instead of having the auxiliary variables in it).
Houtan: for the auxiliary variables related to the expectation operator, you can reuse the framework that I have setup.
- in SymbolTable.hh, add a new enum to aux_var_t, a new method for
adding your type of aux var, and if needed new fields to AuxVarInfo
- add a new method to class DynamicModel (similar to those for
substituting leads and lags)
- call that new method from ModFile::transformPass(), *before* the
methods substituting leads and lags
- for the initialization of new aux variables (since they are not
declared in the "initval" block, the preprocessor needs to give an initial value to them): you need to add your new auxiliary equations to ModelTree::aux_equations; this should suffice, the mechanism that I have setup in DynamicModel::fillEvalContext() and StaticModel::writeAuxInitval() should take care of it
Best,
-- Sébastien Villemot
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Le mardi 06 octobre 2009 à 01:40 -0400, houtan a écrit :
I just would like to check two things regarding the implementation of the Expectation operator:
- Where should I check that arg1 is numeric in
"EXPECTATION(arg1)(arg2)": during parsing, within the checkPass(), or during the transformPass() while dealing with the expectation operator?
The checkPass() is probably a better place.
However, I'm not sure whether you should allow any arbitrary expression as the first argument of the EXPECTATION operator. For the moment, we are only accepting signed integers. So IMHO it is probably better to enforce this restriction during the parsing, using the "signed_integer" rule of the Bison parser.
- I also want to make sure that, after creating auxiliary variables
for every instance of oExpectation, I should erase the associated BinaryOpNode.
No, you should not erase any node. Your node may be shared with another expression with which you have not yet dealt. And it does not matter if the expression tree contains unused nodes: they are simply not referenced by the top level equations/derivatives, but this is not a problem. If the tree grows too much, we could implement a garbage collector, but memory consumption does not seem to be an issue for the moment.
Best,
-
houtan -
Marco Ratto -
Sébastien Villemot