dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-02-21T15:03:32Zhttps://git.dynare.org/Dynare/dynare/-/issues/145when cross-compiling, the host prefix is not added to "ar"2013-02-21T15:03:32ZSébastien Villemotwhen cross-compiling, the host prefix is not added to "ar"When building a static library (as in preprocessor/macro), the build system will always use "ar" (instead of "i686-w64-mingw32-ar" for example).
In most cases this is not a problem.
The problem can happen if one has only the cross-compiling binutils, but not the native binutils, as for example in a Cygwin install where only the packages listed on the wiki page are installed.
When building a static library (as in preprocessor/macro), the build system will always use "ar" (instead of "i686-w64-mingw32-ar" for example).
In most cases this is not a problem.
The problem can happen if one has only the cross-compiling binutils, but not the native binutils, as for example in a Cygwin install where only the packages listed on the wiki page are installed.
4.2https://git.dynare.org/Dynare/dynare/-/issues/144implement solve_algo=0 for Octave2013-02-21T15:03:32ZSébastien Villemotimplement solve_algo=0 for Octavefsolve() has a slightly different syntax under Octave
Need to adapt dynare_solve.m
fsolve() has a slightly different syntax under Octave
Need to adapt dynare_solve.m
4.2https://git.dynare.org/Dynare/dynare/-/issues/161Under Octave, gamma priors fail when variance is too small2013-02-21T15:03:07ZSébastien VillemotUnder Octave, gamma priors fail when variance is too smallThis is reproducible on file RBC_Est.mod distributed with the user guide, which has two gamma priors.
The problem is related to a bug in Octave:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493869
It may also affect beta priors which rely on gaminv() function.
A minimal solution would be to give a sensible error message to the user, so that he knows he has to increase the variance.
A better solution would be to reimplement gaminv.
This is reproducible on file RBC_Est.mod distributed with the user guide, which has two gamma priors.
The problem is related to a bug in Octave:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493869
It may also affect beta priors which rely on gaminv() function.
A minimal solution would be to give a sensible error message to the user, so that he knows he has to increase the variance.
A better solution would be to reimplement gaminv.
4.3https://git.dynare.org/Dynare/dynare/-/issues/160Add derivatives of static model w.r.t. parameters2013-02-21T15:03:07ZSébastien VillemotAdd derivatives of static model w.r.t. parametersCurrently, the derivatives of the static model w.r.t. parameters are computed using the derivatives of the dynamic model w.r.t. parameters.
It would be more convenient to provide directly these derivatives.
Currently, the derivatives of the static model w.r.t. parameters are computed using the derivatives of the dynamic model w.r.t. parameters.
It would be more convenient to provide directly these derivatives.
https://git.dynare.org/Dynare/dynare/-/issues/157histval + stoch_simul(periods=...) + forecast gives wrong result2013-02-21T15:03:06ZSébastien Villemothistval + stoch_simul(periods=...) + forecast gives wrong resultIf there is a histval block, followed by stoch_simul using empirical simulations ("periods" option), then the information provided by histval is lost (the "oo_.endo_simul" structure, which contains the histval information, is completely rewritten).
A subsequent forecast command wrong results, since it will not use histval as starting point.
If there is a histval block, followed by stoch_simul using empirical simulations ("periods" option), then the information provided by histval is lost (the "oo_.endo_simul" structure, which contains the histval information, is completely rewritten).
A subsequent forecast command wrong results, since it will not use histval as starting point.
4.3https://git.dynare.org/Dynare/dynare/-/issues/158Bug in diffuse Kalman smoother2013-02-21T15:03:06ZSébastien VillemotBug in diffuse Kalman smoother4.2https://git.dynare.org/Dynare/dynare/-/issues/156distclean doesn't work if Dynare was built with --disable-octave2013-02-21T15:03:06ZSébastien Villemotdistclean doesn't work if Dynare was built with --disable-octaveThis seems to be a problem with the options of the build system.
This seems to be a problem with the options of the build system.
https://git.dynare.org/Dynare/dynare/-/issues/154Change build process to make libslicot optional on Mac OS X2013-02-21T15:03:06ZSébastien VillemotChange build process to make libslicot optional on Mac OS XXCode doesn't provide a Fortran compiler so Mac users will either have to find one precompiled or compile it on their own. Hence, libslicot should be optional in the build process.
XCode doesn't provide a Fortran compiler so Mac users will either have to find one precompiled or compile it on their own. Hence, libslicot should be optional in the build process.
4.2https://git.dynare.org/Dynare/dynare/-/issues/176preprocessor fails when external functions are assigned to model local variables2013-02-21T15:01:29ZSébastien Villemotpreprocessor fails when external functions are assigned to model local variables4.3https://git.dynare.org/Dynare/dynare/-/issues/175bug in discretionary_policy_engine.m2013-02-21T15:01:29ZSébastien Villemotbug in discretionary_policy_engine.m- first function is not terminated by 'end' contrarily to the other ones. Matlab (r2010b) is missing it.
- W may not be initialized correctly. ./tests/discretionary_policy/dennis_1.mod is an example. Because of above, Matlab is missing it, but Octave detects it.
- first function is not terminated by 'end' contrarily to the other ones. Matlab (r2010b) is missing it.
- W may not be initialized correctly. ./tests/discretionary_policy/dennis_1.mod is an example. Because of above, Matlab is missing it, but Octave detects it.
https://git.dynare.org/Dynare/dynare/-/issues/174Remove options_.planner_discount from preprocessor and .m files2013-02-21T15:01:29ZSébastien VillemotRemove options_.planner_discount from preprocessor and .m filesThis is no longer necessary and can be cleaned out of the code.
This is no longer necessary and can be cleaned out of the code.
4.3https://git.dynare.org/Dynare/dynare/-/issues/173fix license problems in GSA2013-02-21T15:01:29ZSébastien Villemotfix license problems in GSASome files in the matlab/gsa subdirectory have copyright status incompatible with inclusion in Dynare. At least:
fdjac.m
LPTAU.m
optget.m
Sampling_Function_2.m
Other files do not have any copyright notice, their status should be checked.
The copyright status of the GSA manual is not explicited.
Once these issues are fixed, the license.txt file should be updated accordingly.
Some files in the matlab/gsa subdirectory have copyright status incompatible with inclusion in Dynare. At least:
fdjac.m
LPTAU.m
optget.m
Sampling_Function_2.m
Other files do not have any copyright notice, their status should be checked.
The copyright status of the GSA manual is not explicited.
Once these issues are fixed, the license.txt file should be updated accordingly.
https://git.dynare.org/Dynare/dynare/-/issues/171implement the possibility of passing macro-processor defines on the command-line2013-02-21T15:01:29ZSébastien Villemotimplement the possibility of passing macro-processor defines on the command-line...like gcc does with the -D option.
...like gcc does with the -D option.
4.3https://git.dynare.org/Dynare/dynare/-/issues/170document macro-processor in the reference manual2013-02-21T15:01:28ZSébastien Villemotdocument macro-processor in the reference manualAnd also, mention the fact that it is not possible to create a macro-loop around the model block.
And also, mention the fact that it is not possible to create a macro-loop around the model block.
4.3https://git.dynare.org/Dynare/dynare/-/issues/167unit_root_vars should be made obsolete2013-02-21T15:01:28ZSébastien Villemotunit_root_vars should be made obsoleteThe unit_root_vars command should be removed.
For a model with unit root vars, it is up to the user to provide a steadystate file, and Dynare cannot check its validity.
The "check" command should probably have a flag to tell it not to recompute the steady state (or that could be a flag on the "model" command).
Note also that there is still some code in estimation which uses options_.unit_root_vars.
The unit_root_vars command should be removed.
For a model with unit root vars, it is up to the user to provide a steadystate file, and Dynare cannot check its validity.
The "check" command should probably have a flag to tell it not to recompute the steady state (or that could be a flag on the "model" command).
Note also that there is still some code in estimation which uses options_.unit_root_vars.
4.3https://git.dynare.org/Dynare/dynare/-/issues/169recent change to oo_.steady_state breaks estimation2013-02-21T15:01:28ZSébastien Villemotrecent change to oo_.steady_state breaks estimationThe commit 9f7cfaec007f0d4aa805047823c3fb4ce020d6b9 has broken estimation, in particular of fs2000.mod.
The mode optimization fails:
POSTERIOR KERNEL OPTIMIZATION PROBLEM!
(minus) the hessian matrix at the "mode" is not positive definite!
=> posterior variance of the estimated parameters are not positive.
You should try to change the initial values of the parameters using
the estimated_params_init block, or use another optimization routine.
warning: The results below are most likely wrong!
Commenting out line 123 of resol.m fixes the problem:
oo_.steady_state = steady_state;
The commit 9f7cfaec007f0d4aa805047823c3fb4ce020d6b9 has broken estimation, in particular of fs2000.mod.
The mode optimization fails:
POSTERIOR KERNEL OPTIMIZATION PROBLEM!
(minus) the hessian matrix at the "mode" is not positive definite!
=> posterior variance of the estimated parameters are not positive.
You should try to change the initial values of the parameters using
the estimated_params_init block, or use another optimization routine.
warning: The results below are most likely wrong!
Commenting out line 123 of resol.m fixes the problem:
oo_.steady_state = steady_state;
https://git.dynare.org/Dynare/dynare/-/issues/168steady_state operator + oo_.steady_state versus dr.ys2013-02-21T15:01:28ZSébastien Villemotsteady_state operator + oo_.steady_state versus dr.ysThe steady_state operator is currently implemented via the global variable oo_.steady_state in *_dynamic.m
It would be preferable to pass it as argument
It is also necessary to clarify the respective role of oo_.steady_state and dr.ys
In perfect foresight models where the terminal steady state is different from the initial one, we need to clarify which steady state the steady_state operator refers to.
Whatever change is made, must be done for __dynamic.m *_dynamic.mex_ and in bytecode
The steady_state operator is currently implemented via the global variable oo_.steady_state in *_dynamic.m
It would be preferable to pass it as argument
It is also necessary to clarify the respective role of oo_.steady_state and dr.ys
In perfect foresight models where the terminal steady state is different from the initial one, we need to clarify which steady state the steady_state operator refers to.
Whatever change is made, must be done for __dynamic.m *_dynamic.mex_ and in bytecode
https://git.dynare.org/Dynare/dynare/-/issues/165Fix problems with Octave 3.42013-02-21T15:01:28ZSébastien VillemotFix problems with Octave 3.4https://git.dynare.org/Dynare/dynare/-/issues/194Clarify Slicot licensing terms2013-02-21T15:00:43ZSébastien VillemotClarify Slicot licensing termsCurrently Dynare (unstable) distributes its own copy of libslicot (www.slicot.org). It is used in the Kalman Steady State DLL (at least).
As of July 15, 2011, it is no longer possible to download libslicot from its website. It says that the library is currently undergoing a relicensing.
We need to clarify this with Slicot authors to see if we can continue distributing it with Dynare.
Currently Dynare (unstable) distributes its own copy of libslicot (www.slicot.org). It is used in the Kalman Steady State DLL (at least).
As of July 15, 2011, it is no longer possible to download libslicot from its website. It says that the library is currently undergoing a relicensing.
We need to clarify this with Slicot authors to see if we can continue distributing it with Dynare.
https://git.dynare.org/Dynare/dynare/-/issues/193add new sensitivity options2013-02-21T15:00:43ZSébastien Villemotadd new sensitivity optionspvalue_ks (default 0.001) threshold pvalue for significant Kolmogorov
Smirnov test (i.e. plot parameters with pvalue<pvalue_ks)
pvalue_corr (default 0.001) threshold pvalue for significant correlation in filtered samples (i.e. plot bivariate samples when pvalue<pvalue_corr)
pvalue_ks (default 0.001) threshold pvalue for significant Kolmogorov
Smirnov test (i.e. plot parameters with pvalue<pvalue_ks)
pvalue_corr (default 0.001) threshold pvalue for significant correlation in filtered samples (i.e. plot bivariate samples when pvalue<pvalue_corr)
4.3