Le mercredi 16 septembre 2009 à 20:39 -0400, houtan a écrit :
> Just to make sure I understand completely, the reason you proposed the
> method above over the one outlined earlier (which seemed to replace
> the EXPECTATION operator as it was encountered, and is outlined below
> for reference) is that since we are declaring auxiliary variables on
> the fly, and since we are creating the modfile on the fly as well, we
> want to be certain that we do not declare a variable for our use (in
> this case aux*) that the user may have referenced at a later point in
> their .m file.
This is actually not the main reason for my proposing another solution.
But this is a side effect, though.
> If this is wrong and all of the symbols have in fact been declared in
> the SymbolTable by the time the parser begins to create expression
> trees, would the following be a valid procedure for implementing the
> Expectation operator?
>
>
> Following the names EXPECTATION(iArg1)(iArg2),
>
>
> in NodeID DataTree::AddExpectation(NodeID iArg1, NodeID iArg2)
> * Create new auxiliary variable, auxvar(iArg1) via a separate
> protected function (using addSymbol, addVariable) that will find a
> unique variable name
> * Add equation: auxvar = iArg2(-iArg1) to the model tree
> * return the NodeID of auxvar(iArg1) (as requested
> here:
http://www.dynare.org/DynareWiki/NewOperators )
>
>
> If not, what is the advantage of the method proposed earlier over the
> one contained herein?
pass in the preprocessor. In my mind, parsing is only building an
expression tree, exactly reflecting what the user has written. So I
don't like the idea of doing this on-the-fly. I prefer to clearly
separate things in several tasks.
For the moment the preprocessor has 4 steps:
* parsing
* checking (ModFile::checkPass())
* computing (ModFile::computingPass())
* output writing (ModFile::writeOutputFiles())
All the treatment of the expectation operator (adding auxiliary
variables and substituting the operator by the new variables) should be
done at the beginning of the computing pass. The checking pass may be
used to identify the set of expectation operators to be replaced (but
only identifying, since it is meant to be "read-only").
Also note that, with Michel, we agreed on the fact that the auxiliary
variable names should be meaningful for the user, because she will see
it in the output of Dynare. The name needs also to be a valid MATLAB
variable name, because we construct output structures with the
endogenous names. So for example the auxiliary variable created by
expression E(1)(x) could be called E_1_x, which is both meaningful and
valid.
If it happens that this name collides with a variable declared by the
user, then the preprocessor should exit with an error message, telling
the user to use another name in order to avoid confusion (even for his
own sake).
> Also, why does the NewOperators page say we need to keep a list of new
> auxiliary variables? This wouldn't be necessary if the idea proposed
> herein is correct (but certainly would be if we were to follow the
> method proposed earlier).
It is up to you to decide if you need such a list in the implementation.
My impression is that you don't need it, but I may be wrong.
> Finally, the NewOperators page states "if the expression has not been
> encountered in the file, create a new auxiliary variable..." Shouldn't
> this new auxiliary variable be created, regardless of whether or not
> the expression has already been encountered?
This sentence was only meaningful in the context of an on-the-fly
substitution. It is obsolete in the setting that I have in mind.
Best,
--
Sébastien Villemot