October 2009 - Dev - dynare.org

Re: [DynareDev] [Trac] #1: Implement conditional forecasts
by Trac Dynare 16 Oct '09

16 Oct '09

#1: Implement conditional forecasts ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: stepan Type: feature | Status: assigned Priority: major | Milestone: 4.1 Component: Core M-files | Version: Resolution: | Keywords: ---------------------------+------------------------------------------------ Comment(by sebastien): New interface has been implemented and documented in r3049. Note that for "plot_conditional_forecast", an argument of -1 means to M-function plot_icforecast() means that the user did not specified a number of periods, and that the plot should have as many periods as computed in "conditional_forecast" Still need to: * adapt M-functions according to the new calling syntax created by the preprocessor * verify entries in the reference manual (specially for default values of options) * update the wiki page [http://www.dynare.org/DynareWiki/ConditionalForecast] and move it to the 4.1 section on the "new features" page -- Ticket URL: <https://www.dynare.org/trac/ticket/1#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

New identification files
by Sébastien Villemot 15 Oct '09

15 Oct '09

Hi Marco, Thanks for your identification routines. Just to remind you that you need to add copyright notices at the top of your new files, as explained on: http://www.dynare.org/DynareWiki/CodingStandards#Copyrightnotice-1 Best, -- Sébastien Villemot

3 8

loglinear models
by G. Perendia 12 Oct '09

12 Oct '09

Looking at DR1.m I noticed that the dr1.m code will not reach log-linear test and the log-linear transformation of the model ghx and ghu matrices (if needed) on line 449 if it is only backward looking due to a return statement on line 266. Is that intended behaviour? Best regards George

3 4

[Trac] #47: Uninformative error message when failing to create subdirectory
by Trac Dynare 12 Oct '09

12 Oct '09

#47: Uninformative error message when failing to create subdirectory --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- If MOD file is <filename>.mod, CheckPath.m tries to create a directory called <filename>. If there already exists a file (not a directory) with that name (i.e. the same filename than the MOD file, but without extension), Dynare crashes and the error message is not very informative. A more explicit message should be displayed. See: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2284&p=4507 -- Ticket URL: <https://www.dynare.org/trac/ticket/47> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #15: Add order 3 derivatives in USE_DLL mode (for k-order)
by Trac Dynare 12 Oct '09

12 Oct '09

#15: Add order 3 derivatives in USE_DLL mode (for k-order) ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: sebastien Type: enhancement | Status: closed Priority: major | Milestone: 4.1 Component: Preprocessor | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: accepted => closed * resolution: => fixed Comment: Fixed in r3036 -- Ticket URL: <https://www.dynare.org/trac/ticket/15#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] operators
by Michel Juillard 08 Oct '09

08 Oct '09

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(a)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 > > >

4 11

New build system
by Sébastien Villemot 07 Oct '09

07 Oct '09

Hi everyone, I have finished the new build system for Dynare. With a single "make" command you can now build Dynare preprocessor, MEX files for MATLAB and Octave, Dynare++, all the documentation. The procedure is described on: http://www.dynare.org/DynareWiki/BuildingDynareFromSource I would like to get your feedback about this, both in terms of functionality and of documentation. Two more platforms still need to be tested and documented: * Windows 64-bit, using MinGW64 * MacOS I will take care of Windows 64-bit. Houtan: when you have the time, could you test the procedure on MacOS? Maybe you could also write a section on the wiki page when you have finished. I will soon integrate the k-order DLL to that build system. Best, -- Sébastien Villemot

3 18

[Trac] #42: Fix problem of order 2 with leads of two or more
by Trac Dynare 07 Oct '09

07 Oct '09

#42: Fix problem of order 2 with leads of two or more --------------------------+------------------------------------------------- Reporter: sebastien | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/42> Dynare <http://www.dynare.org> The Dynare project

1 2

Leads and lags of 2 or more
by Sébastien Villemot 06 Oct '09

06 Oct '09

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

3 5