dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-08-19T15:05:51Zhttps://git.dynare.org/Dynare/dynare/-/issues/234add @#elseif to macroprocessor2019-08-19T15:05:51ZSébastien Villemotadd @#elseif to macroprocessorsaves users from:
if
else
if
else
endif
endif
saves users from:
if
else
if
else
endif
endif
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/232Create dummy M file for making clear some calling dependencies2014-01-28T16:52:47ZSébastien VillemotCreate dummy M file for making clear some calling dependenciesCurrently some M-functions are called from M-files using eval() instead of calling them directly.
As a result, these functions appear as orphaned in the M2HTML graph, and also do not necessarily appear when doing a grep on M-files.
The...Currently some M-functions are called from M-files using eval() instead of calling them directly.
As a result, these functions appear as orphaned in the M2HTML graph, and also do not necessarily appear when doing a grep on M-files.
The risk is that one may remove these functions, thinking they are unused.
The proposed solution is to create a dummy M-file that would directly call these functions (possibly with comments indicating the actual place of the real calls)
https://git.dynare.org/Dynare/dynare/-/issues/233Smoother on calibrated models2013-02-21T14:59:20ZSébastien VillemotSmoother on calibrated modelsAdd the possibility of running the smoother on a calibrated model.
It may be already possible to do so, by giving no estimated_params and then running estimation with mode_compute=0. If this indeed works, we need to add an interface by ...Add the possibility of running the smoother on a calibrated model.
It may be already possible to do so, by giving no estimated_params and then running estimation with mode_compute=0. If this indeed works, we need to add an interface by creating a new MOD-file command that would output the right call to estimation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/231DsgeLikelihood_hh.m was removed when DsgeLikelihood.m was replaced by dsge_li...2013-02-21T14:59:20ZSébastien VillemotDsgeLikelihood_hh.m was removed when DsgeLikelihood.m was replaced by dsge_likelihood.mDsgeLikelihood_hh.m needs to be replaced by dsge_likelihood_hh.m that is needed by newrat.m and tests/fs2000/fs2000d.mod
All the Kalman filter routines needs also to return llik, the vector of loglikelihood per observation.
DsgeLikelihood_hh.m needs to be replaced by dsge_likelihood_hh.m that is needed by newrat.m and tests/fs2000/fs2000d.mod
All the Kalman filter routines needs also to return llik, the vector of loglikelihood per observation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/230Parallelize the testsuite2013-02-21T14:59:20ZSébastien VillemotParallelize the testsuiteCurrently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie i...Currently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie in a separate list of tests which will not be (fully) parallelized.
Need to think about a way to aggregate the tests results into one report.
https://git.dynare.org/Dynare/dynare/-/issues/229update markov_switching statement2013-02-21T14:59:20ZSébastien Villemotupdate markov_switching statement- remove the regime option
- replace number_of_states with number_of_regimes
- add restrictions option
- allow duration to accept a vector of length number_of_regimes
- remove the passing of INF_CONSTANT to duration
See http://www.dynar...- remove the regime option
- replace number_of_states with number_of_regimes
- add restrictions option
- allow duration to accept a vector of length number_of_regimes
- remove the passing of INF_CONSTANT to duration
See http://www.dynare.org/DynareWiki/MarkovSwitchingInterface
4.3https://git.dynare.org/Dynare/dynare/-/issues/228document functions for which we have changed the calling sequence in unstable2013-02-21T14:59:20ZSébastien Villemotdocument functions for which we have changed the calling sequence in unstableThe changes that we have made to several functions in unstable will break the code of people who are calling these functions directly.
This will make a big mess when we release 4.3
We need to document those changes on the wiki
The changes that we have made to several functions in unstable will break the code of people who are calling these functions directly.
This will make a big mess when we release 4.3
We need to document those changes on the wiki
4.3https://git.dynare.org/Dynare/dynare/-/issues/227bug in 2nd order approximation if one variable is not present in the current ...2013-02-21T14:59:20ZSébastien Villemotbug in 2nd order approximation if one variable is not present in the current periodthis should be dealt with in the same time as #94
this should be dealt with in the same time as #94
4.3https://git.dynare.org/Dynare/dynare/-/issues/226New estimation2023-09-27T15:08:19ZSé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).7.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/224Erase generated steady state files2013-02-21T14:59:19ZSébastien VillemotErase generated steady state filesOld steadystate files (generated by the steady_state block) should be erased before any computation. In the current setting, if the steady_state block is commented out and if the user changes the model (for instance by changing a paramet...Old steadystate files (generated by the steady_state block) should be erased before any computation. In the current setting, if the steady_state block is commented out and if the user changes the model (for instance by changing a parameter to an exogenous variable) then Dynare crashes (because a parameter is then missing).
https://git.dynare.org/Dynare/dynare/-/issues/225inverse_gamma_specification2013-02-21T14:59:19ZSébastien Villemotinverse_gamma_specificationThe secant method used to convert the prior mean and std to s and nu is buggy in some cases. A check on the size of the error should be added.
An example is reported on the forum. For (mean 0.75, sd 0.1), the result of inverse_gamma_sp...The secant method used to convert the prior mean and std to s and nu is buggy in some cases. A check on the size of the error should be added.
An example is reported on the forum. For (mean 0.75, sd 0.1), the result of inverse_gamma_specification(0.75,0.1,1) is
s = 11.2136
nu = 21.5870
But the correct answer is
s = 16.2409
nu = 30.3684
Before entering in the while loop the error is 84.9627 and on exit the (monotically growing) error is 4.4287e+10.
https://git.dynare.org/Dynare/dynare/-/issues/223add @#ifdef functionality to macroprocessor2013-02-21T14:59:19ZSébastien Villemotadd @#ifdef functionality to macroprocessorCurrently, we only support @#if, meaning that every macro variable must be predefined. For large mod files with many clauses where you may want to include/exclude portions easily, this becomes cumbersome because it requires you to define...Currently, we only support @#if, meaning that every macro variable must be predefined. For large mod files with many clauses where you may want to include/exclude portions easily, this becomes cumbersome because it requires you to define all macro used anywhere to be equal to zero at the beginning of the modfile.
It is also cumbersome when certain macro variables are only defined based on the existence of others, making the definition at the beginning of the mod file all that much longer.
See GPM6.mod to get the general idea.
4.3https://git.dynare.org/Dynare/dynare/-/issues/222Give a more explicit error message when there is no 'estimated_params' but es...2013-02-21T14:59:19ZSébastien VillemotGive a more explicit error message when there is no 'estimated_params' but estimation is runI attach the MOD file and data.
Reported on the forum: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3402
I attach the MOD file and data.
Reported on the forum: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3402
https://git.dynare.org/Dynare/dynare/-/issues/221add support for Excel files in Octave2013-02-21T14:59:19ZSébastien Villemotadd support for Excel files in OctaveThe xlsread function is in the octave-io Forge package. The package seems to need octave-java in turn.
The xlsread function is in the octave-io Forge package. The package seems to need octave-java in turn.
4.3https://git.dynare.org/Dynare/dynare/-/issues/220add a homotopy mode for simul() and for steady with endval2016-06-01T12:23:27ZSébastien Villemotadd a homotopy mode for simul() and for steady with endvalCurrently homotopy only exist for steady with initval.
These features would be useful for GIMF at the IMF.
Currently homotopy only exist for steady with initval.
These features would be useful for GIMF at the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/219steady_state_model broken for lags higher than 22013-02-21T14:59:19ZSébastien Villemotsteady_state_model broken for lags higher than 2The attached example shows a case where steady_state_model is broken.
There is a problem in the ordering of auxiliary equations.
The problem does not appear with a lag of 2 (if N=2).
Since the problem is present in version 4.2.2 but n...The attached example shows a case where steady_state_model is broken.
There is a problem in the ordering of auxiliary equations.
The problem does not appear with a lag of 2 (if N=2).
Since the problem is present in version 4.2.2 but not in version 4.2.1, it is likely to be linked to the fix for ticket #214.
User bug report: http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3396
https://git.dynare.org/Dynare/dynare/-/issues/217permit Dynare to compute k order perturbation2019-04-29T16:45:54ZSébastien Villemotpermit Dynare to compute k order perturbationThe current restriction is order ≤ 3.
The current restriction is order ≤ 3.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/218Remove set_stationary_variables_list.m2013-02-21T14:59:19ZSébastien VillemotRemove set_stationary_variables_list.mThis function is basically useless now that unit_root_vars has been removed.
It is however still called from several places.
This function is basically useless now that unit_root_vars has been removed.
It is however still called from several places.
4.3https://git.dynare.org/Dynare/dynare/-/issues/216Behaviour of "nograph" option is not consistent2013-02-21T14:59:19ZSébastien VillemotBehaviour of "nograph" option is not consistentThe reference manual says that with the "nograph" options, Dynare "doesn't do the graphs".
This options indeed prevents Dynare from displaying graphs, but it still creates PDF/EPS files in some parts of the code (but not all).
For exam...The reference manual says that with the "nograph" options, Dynare "doesn't do the graphs".
This options indeed prevents Dynare from displaying graphs, but it still creates PDF/EPS files in some parts of the code (but not all).
For example, stoch_simul+nograph won't create PDF/EPS files for IRFs, but estimation+nograph will still create some PDF/EPS files.
This is inconsistent. Moreover, some users would like to have the possibility of not saving the graphs (http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=3362)
I think we should either decide that "nograph" means "do not display nor save graphs", or create a new option like "nographsave" which would allow full flexibility with regard to displaying/saving graphs.
4.3https://git.dynare.org/Dynare/dynare/-/issues/215name clash between matlab/bfsgi.m and matlab/ms-sbvar/cstz/bfgsi.m2013-02-21T14:59:19ZSébastien Villemotname clash between matlab/bfsgi.m and matlab/ms-sbvar/cstz/bfgsi.mThe two files are essentially the same except for display.
They should either be merged (adding dispIndx as an argument), or one of the two should be renamed.
The two files are essentially the same except for display.
They should either be merged (adding dispIndx as an argument), or one of the two should be renamed.
4.3