Re: [DynareDev] operators

houtan wrote:

Dear Sébastien and Michel,

I have made the requested changes but have a few minor questions.

1. 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?

2. 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(...)".

3. 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.

Thanks Houtan,

you are right, there is a flaw in the specification: oo_ is not know to function <fname>_dynamic.m There are two solutions: 1) 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? Note that what we choose will need to be also implemented in the evaluator of the bytecode.

Best

Michel

I think that's it. Otherwise, the changes were pretty straightforward. I have uploaded it to svn.

Best, Houtan

2009/9/10 Sébastien Villemot <sebastien.villemot@ens.fr mailto:sebastien.villemot@ens.fr>

Le mercredi 09 septembre 2009 à 19:47 -0400, houtan a écrit :
> For me, the only way we could have the desired output for a dynamic
> model (using the proposed procedure of modifying only
> UnaryOpNode::writeOutput() and dropping datatree.isDynamic()) is by
> using a modified version of IDEA 4 (shown below). In other words, I
> don't see how changing the output_type from dynamic to static will
> produce the dynamic model output (oo_.(exo_)steady_state(...)),
which
> is only located under case oMatlabOutsideModel.

You're perfectly right, for the moment oMatlabOutsideModel is the only
one which creates the right output for Matlab code. It is my mistake,
sorry for creating confusion and for not having read carefully your
message.

I think that we should create new types in the ExprOutputType
enumeration. For example we could create something like
oMatlabDynamicSteadyStateOperator, which would be used when
encountering
a steady state operator in the dynamic model. It might end up to do
exactly the same than oMatlabOutsideModel, but it is probably more
readable to use a different name since it's a different
functionnality.

We also need to deal with three other types of output:
* C output in oCDynamicModel: since we are going to drop C output
in the
near future, if you encounter a steady state operator in that
mode, just
exit the preprocessor with a message like "not implemented"
* Matlab output for sparse model (oMatlabDynamicModelSparse): I
need to
discuss with Ferhat on how to deal with that: for the moment, just
exit
with a "not implemented" message
* Latex output for dynamic model (oLatexDynamicModel): here again we
should create a new output type (such as
oLatexDynamicSteadyStateOperator), which would add bars over variable
names (for variable $x$, it could write $\bar{x}$)
* Bytecode output: you need not to modify UnaryOpNode::compile(). We
should however modify the bytecode interpreter (bytecode DLL in
mex/sources/bytecode). I also need to discuss that with Ferhat,
just do
nothing for the moment about that.


> Also, might we still need the isDynamic method to use in
> UnaryOpNode::composeDerivatives()?

You're probably right, I think you can't escape using this method at
this point.


As you can see, implementing operator is not so straightforward, so
don't worry if it takes times to converge to the best solution.

Best,

--
Sébastien Villemot