dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-08-17T10:25:22Zhttps://git.dynare.org/Dynare/dynare/-/issues/444Document remaining options of nonlinear filters2021-08-17T10:25:22ZStéphane Adjemianstepan@adjemian.euDocument remaining options of nonlinear filtersWe need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way...We need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way of setting these options
- [x] Add information to the manual (a link to the wiki is the minimum)5.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-08-17T10:24:37ZJohannes PfeiferRamsey: document potential problems with auxiliary variables for timeless perspectiveSee https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/16See https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/165.xhttps://git.dynare.org/Dynare/dynare/-/issues/339Clarify difference between Bayesian HPDI and classical confidence bands in ma...2021-08-17T10:24:01ZJohannes PfeiferClarify 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/1605Better document behavior of steady_state operator2021-08-17T10:23:21ZJohannes PfeiferBetter document behavior of steady_state operatorSee https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3See https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3https://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)https://git.dynare.org/Dynare/dynare/-/issues/1808Update or remove https://archives.dynare.org/DynareWiki/EquationsTags2021-08-17T10:04:38ZJohannes PfeiferUpdate or remove https://archives.dynare.org/DynareWiki/EquationsTagsThe information there seems outdated or redundant, but it is still linked from the manual.The information there seems outdated or redundant, but it is still linked from the manual.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/240rewrite getPowerDeriv assignments in temporary terms2021-08-15T19:50:56ZSé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;
end
https://git.dynare.org/Dynare/dynare/-/issues/312Allow User to choose Mean or Median statistics2021-08-15T19:47:20ZJohannes PfeiferAllow 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 p...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/530checking singularity in first order approximation2021-08-15T19:44:22ZMichelJuillardchecking singularity in first order approximationCurrently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramse...Currently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramsey_policy)
2) Should we care for estimation? Should expand the implicit prior to b10 and A_ non-singular?
3) If b10 is singular, the model has a problem: it is not possible to determine some static variable from the solution of the dynamic part of the model
4) The conditions under which A_ can be singular are mode difficult to determine.
https://git.dynare.org/Dynare/dynare/-/issues/829Rewrite local_state_space_iteration_2 routine2021-08-15T19:40:51ZStéphane Adjemianstepan@adjemian.euRewrite local_state_space_iteration_2 routineSeparate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository, particularly https://git.dynare.org/Dynare/particles/-/issues/2Separate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository, particularly https://git.dynare.org/Dynare/particles/-/issues/2Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1400Investigate dseries problems in parallel execution2021-08-15T19:10:35ZJohannes PfeiferInvestigate dseries problems in parallel executionWhen executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current cons...When executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1573Allow mode_compute to be a vector2021-08-15T19:07:59ZJohannes PfeiferAllow mode_compute to be a vectorAllow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.Allow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2021-08-15T19:07:37ZJohannes PfeiferMake dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903See https://forum.dynare.org/t/calculating-rmses/119036.xhttps://git.dynare.org/Dynare/dynare/-/issues/1778Identification toolbox: support measurement errors2021-08-15T19:03:09ZWilli Mutschlerwilli@mutschler.euIdentification toolbox: support measurement errorsThe identification toolbox should be able to support measurement errors.The identification toolbox should be able to support measurement errors.6.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2021-08-15T16:14:51ZStéphane Adjemianstepan@adjemian.euBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent sh...In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1809rbc.mod: error: sq_string cannot be indexed with .2021-08-15T07:29:26Zyuri@FreeBSDrbc.mod: error: sq_string cannot be indexed with .This model fails:
```
error: sq_string cannot be indexed with .
error: called from
dyntable at line 35 column 1
driver at line 200 column 1
dynare at line 293 column 1
```
Version: 4.6.4
Octave: 6.3.0
OS: FreeBSD 13
[rbc...This model fails:
```
error: sq_string cannot be indexed with .
error: called from
dyntable at line 35 column 1
driver at line 200 column 1
dynare at line 293 column 1
```
Version: 4.6.4
Octave: 6.3.0
OS: FreeBSD 13
[rbc.mod](/uploads/626e8e116f4fa959325cddeeee600244/rbc.mod)https://git.dynare.org/Dynare/dynare/-/issues/1806Manual: use proper bibliography management2021-08-10T08:48:34ZJohannes PfeiferManual: use proper bibliography managementWe may want to transition to e.g. https://pypi.org/project/sphinxcontrib-bibtex/We may want to transition to e.g. https://pypi.org/project/sphinxcontrib-bibtex/6.xhttps://git.dynare.org/Dynare/dynare/-/issues/520Weibull prior distibution2021-08-02T11:31:20ZMichelJuillardWeibull prior distibutionCMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
CMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
4.5Johannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/750Decide on treatment of prior truncation during estimation2021-08-02T11:28:56ZJohannes PfeiferDecide on treatment of prior truncation during estimationWe need to decide on how to proceed, see https://github.com/DynareTeam/dynare/commit/aa503abfa79145efc0840c79210e795e1b76df84
We need to decide on how to proceed, see https://github.com/DynareTeam/dynare/commit/aa503abfa79145efc0840c79210e795e1b76df84
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2021-07-27T11:37:26ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an ...At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.6.xMarco RattoMarco Ratto