Le vendredi 11 septembre 2009 à 11:07 +0200, Michel Juillard a écrit :
houtan wrote:
I have made the requested changes but have a few minor questions.
Thanks for that.
Just one remark: in your last commit, you didn't follow the C++ coding style convention for the Dynare project (in particular you should never use tabulations, please use spaces instead). I strongly encourage you to switch to GNU Emacs as an editor, since it is very powerful and our coding style is the default style under Emacs. However you can use another editor, provided that you configure it to follow the rules, which are described on: http://www.dynare.org/DynareWiki/CodingStandards
For this commit it is not a real problem, since I plan to use in a few weeks an automatic tool for reindenting all the C++ code of the project. But please pay attention to that for your subsequent commits.
- As we are outputing the tsid as opposed to a variable name, I have
created oLatexDynamicSteadyStateOperator but allowed it to perform the same operation as oMatlabDynamicSteadyStateOperator. Is this OK?
Actually the LaTeX output is something different: it is used to create a LaTeX file for the model, as described on: http://www.dynare.org/DynareWiki/ModelLatexOutput
I fixed the operator for LaTeX output: in the dynamic model, it will add a horizontal bar over the variable name (such as $\bar{x}$)
- Though it is not in the specification on the Operator web page, I
have implemented oMatlabDynamicSteadyStateOperator for eExogenousDet. In this case, it writes "oo_.exo_det_steady_state(...)".
I think this is ok. Note that I also removed some "assert(lag == 0)" in your code: we need to allow the steady state operator to work with exogenous/exogenous_det with non-zero lead/lag.
- Having made the changes, I gave it a first test with example1.mod,
placing the steady_state operater in different places to see if it was parsing correctly. Though it seems to be parsing as per the rules discussed on the web page, in Matlab I did continually encounter the errors of the form: ??? Undefined variable "oo_" or class "oo_.exo_steady_state". ??? Undefined variable "oo_" or class "oo_.steady_state".
I just wanted to bring this to your attention.
you are right, there is a flaw in the specification: oo_ is not know to function <fname>_dynamic.m There are two solutions:
- add steady_state to the list of arguments of this function. This is
probably more elegant. The drawback is that we increase the number of arguments of the function for a rarely used feature 2) call Matlab global variable oo_ from inside <fname>_dynamic.m. The preprocessor can add the code only for those models that actually use the STEADY_STATE operator. In this case, it will be slower than 1), but the code doesn't change for the majority of cases. What do you think, everybody?
I think I prefer solution 2): this operator is probably not used enough to warrant the slowdown which would probably be incurred with solution 1).
Note that what we choose will need to be also implemented in the evaluator of the bytecode.
Ferhat will take care of that.
Best,