Dynare issueshttps://git.dynare.org/groups/Dynare/-/issues2019-11-21T08:36:42Zhttps://git.dynare.org/Dynare/dynare/-/issues/416Document how to do learning with Dynare2019-11-21T08:36:42ZJohannes PfeiferDocument how to do learning with DynareSee http://www.dynare.org/pipermail/dev/2013-May/003256.html
See http://www.dynare.org/pipermail/dev/2013-May/003256.html
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/386k_order_perturbation MEX: error messages are uninformative2021-11-09T19:29:02ZMichelJuillardk_order_perturbation MEX: error messages are uninformativeThe k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.The k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.https://git.dynare.org/Dynare/dynare/-/issues/349Use preprocessor for variable transformation (e.g. exp for doing approximatio...2022-03-30T16:10:38ZJohannes PfeiferUse preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use...An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.6.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes PfeiferChange color scheme of figures to be readable on monochrome printoutsMore information will be provided soon.
More information will be provided soon.
https://git.dynare.org/Dynare/dynare/-/issues/295offer a quiet and a verbose mode2019-06-19T15:37:41ZSébastien Villemotoffer a quiet and a verbose modeSome users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never ...Some users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
https://git.dynare.org/Dynare/dynare/-/issues/294rework option handling2020-05-07T17:47:23ZSébastien Villemotrework option handlingIt's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something t...It's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
https://git.dynare.org/Dynare/dynare/-/issues/285Allow user-specified path for exogenous in extended_path2019-06-19T15:37:42ZSébastien VillemotAllow user-specified path for exogenous in extended_pathThat could be implemented with the shocks blocks.
That could be implemented with the shocks blocks.
https://git.dynare.org/Dynare/dynare/-/issues/248Add tests for the parallelization engine2019-06-19T15:37:42ZSébastien VillemotAdd tests for the parallelization engineMarco RattoMarco Rattohttps://git.dynare.org/Dynare/preprocessor/-/issues/73rewrite getPowerDeriv assignments in temporary terms2021-08-15T19:51:32ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) n...From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end6.xhttps://git.dynare.org/Dynare/dynare/-/issues/226New estimation2021-09-01T14:40:52ZSébastien VillemotNew estimationWrite the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).Write the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/preprocessor/-/issues/76improve derivation engine for derivatives of STEADY_STATE wrt parameters2021-08-17T11:02:43ZSébastien Villemotimprove derivation engine for derivatives of STEADY_STATE wrt parametersCurrently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for...Currently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
https://git.dynare.org/Dynare/dynare/-/issues/163Finish first version of internal documentation2019-06-19T15:37:43ZSébastien VillemotFinish first version of internal documentationSee doc/internals/dynare-internals.org for the first draft.
For the IMF.
See doc/internals/dynare-internals.org for the first draft.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/162Global method: stochastic simulation approach2019-06-19T15:37:43ZSébastien VillemotGlobal method: stochastic simulation approachAs advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
As advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/149Handle missing values in block decomposed version of Kalman filter2021-09-03T16:23:30ZSébastien VillemotHandle missing values in block decomposed version of Kalman filterhttps://git.dynare.org/Dynare/dynare/-/issues/147Accuracy checks2021-11-19T11:16:08ZSébastien VillemotAccuracy checkshttps://git.dynare.org/Dynare/dynare/-/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSébastien VillemotImprove display of decision rules with EXPECTATION operatorCurrently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression)...Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
https://git.dynare.org/Dynare/dynare/-/issues/116IRF: give the possibility to choose the starting point (at least at order 2 a...2022-04-21T19:44:12ZSébastien VillemotIRF: give the possibility to choose the starting point (at least at order 2 and above)In particular, give the possibility to start from the stochastic steady stateIn particular, give the possibility to start from the stochastic steady stateJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/115IRF: add the possibility to change the size of the shocks in the computations2022-04-21T19:43:09ZSébastien VillemotIRF: add the possibility to change the size of the shocks in the computationsAt order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.At order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/7In dr.tex, add a concrete example on a model (by expliciting the matrices)2021-08-17T10:04:38ZSébastien VillemotIn dr.tex, add a concrete example on a model (by expliciting the matrices)