dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-12-23T12:53:54Zhttps://git.dynare.org/Dynare/dynare/-/issues/349Use preprocessor for variable transformation (e.g. exp for doing approximatio...2020-12-23T12:53:54ZJohannes Pfeifer Use 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 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.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.4.7https://git.dynare.org/Dynare/dynare/-/issues/339Clarify difference between Bayesian HPDI and classical confidence bands in ma...2019-11-21T08:36:42ZJohannes Pfeifer Clarify difference between Bayesian HPDI and classical confidence bands in manualMention in manual that ML gives CIs and not HPDIs. More fundamentally, I am not sure whether it is a good idea to store CIs after ML in fields named HPDinf and HPDsup.
Mention in manual that ML gives CIs and not HPDIs. More fundamentally, I am not sure whether it is a good idea to store CIs after ML in fields named HPDinf and HPDsup.
https://git.dynare.org/Dynare/dynare/-/issues/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes Pfeifer Change 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/312Allow User to choose Mean or Median statistics2019-06-19T15:37:41ZJohannes Pfeifer Allow User to choose Mean or Median statisticsCurrently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
Currently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
https://git.dynare.org/Dynare/dynare/-/issues/300Implement k-order derivatives of external functions2019-12-16T14:00:55ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor error
Otherwise order ≥ 3 fails with a cryptic preprocessor error
4.7https://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 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.
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 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.
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/dynare/-/issues/240rewrite getPowerDeriv assignments in temporary terms2019-06-19T15:37:42ZSé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) 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;
end
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;
end
https://git.dynare.org/Dynare/dynare/-/issues/237Document sbvar command2019-11-21T08:36:41ZSébastien VillemotDocument sbvar commandMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/226New estimation2019-06-19T15:37:42ZSé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).
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/172improve derivation engine for derivatives of STEADY_STATE wrt parameters2019-06-19T15:37:42ZSé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 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.
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 filter2019-06-19T15:37:43ZSébastien VillemotHandle missing values in block decomposed version of Kalman filterhttps://git.dynare.org/Dynare/dynare/-/issues/147Accuracy checks2019-11-21T08:36:40ZSé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). 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.
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...2020-05-18T13:05:10ZSé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 state
In particular, give the possibility to start from the stochastic steady state
https://git.dynare.org/Dynare/dynare/-/issues/115IRF: add the possibility to change the size of the shocks in the computations2020-05-18T13:05:11ZSé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.