dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2014-01-28T16:34:37Zhttps://git.dynare.org/Dynare/dynare/-/issues/164consider using bvar provided by Zha and Waggoner instead of our own2014-01-28T16:34:37ZSébastien Villemotconsider using bvar provided by Zha and Waggoner instead of our ownTheir code provides a superset of ours.
Their code provides a superset of ours.
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/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/159gamrnd.m (in matlab/missing/stats): implement selection of alternative method...2018-11-09T10:21:44ZSébastien Villemotgamrnd.m (in matlab/missing/stats): implement selection of alternative methods (3rd argument)Sébastien VillemotSébastien Villemothttps://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/150Optimal policy: discretionary equilibrium2013-02-21T15:03:33ZSébastien VillemotOptimal policy: discretionary equilibrium4.3https://git.dynare.org/Dynare/dynare/-/issues/151BVAR priors: add interface to Marcett-Jarocinski' code2014-01-28T15:13:33ZSébastien VillemotBVAR priors: add interface to Marcett-Jarocinski' codeReference paper: ECB WP no. 1263
http://www.ecb.europa.eu/pub/pdf/scpwps/ecbwp1263.pdf
Reference paper: ECB WP no. 1263
http://www.ecb.europa.eu/pub/pdf/scpwps/ecbwp1263.pdf
https://git.dynare.org/Dynare/dynare/-/issues/148Integrate dr_block.m into the new structure for stochastic solvers2016-06-10T12:49:08ZSébastien VillemotIntegrate dr_block.m into the new structure for stochastic solvers4.5FerhatMihoubiFerhatMihoubihttps://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/146Global method: Chebychev polynomials2016-06-10T13:16:58ZSébastien VillemotGlobal method: Chebychev polynomialshttps://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/143adapt sim1.m for purely forward models and remove simk.m2013-02-21T15:03:52ZSébastien Villemotadapt sim1.m for purely forward models and remove simk.mFixed in 4b2405a0141473145db78e7a7af2754e981e3bae
Fixed in 4b2405a0141473145db78e7a7af2754e981e3bae
4.3https://git.dynare.org/Dynare/dynare/-/issues/142Integrate ACES Linear Quadratic approximation toolbox2014-01-28T15:12:00ZSébastien VillemotIntegrate ACES Linear Quadratic approximation toolboxAnalysis is on:
http://www.dynare.org/DynareWiki/AcesLqImplementationRequirements
Analysis is on:
http://www.dynare.org/DynareWiki/AcesLqImplementationRequirements
https://git.dynare.org/Dynare/dynare/-/issues/139Rename "cygwin" option in "mingw"2013-02-21T15:04:04ZSébastien VillemotRename "cygwin" option in "mingw"The name of the option is misleading since even under Cygwin we internally use MinGW embedded within GCC 3.
The old option should give an error message pointing to the new one.
Example mexopts.bat should be given for at least 3 cases (in the package and in the wiki):
- Cygwin + GCC 3 (hence 32-bit)
- MinGW 32-bit (probably for TDM build)
- MinGW 64-bit (probably for TDM build)
The name of the option is misleading since even under Cygwin we internally use MinGW embedded within GCC 3.
The old option should give an error message pointing to the new one.
Example mexopts.bat should be given for at least 3 cases (in the package and in the wiki):
- Cygwin + GCC 3 (hence 32-bit)
- MinGW 32-bit (probably for TDM build)
- MinGW 64-bit (probably for TDM build)
4.2https://git.dynare.org/Dynare/dynare/-/issues/141Replace strmatch which is a deprecated function in Matlab2013-02-21T15:03:52ZSébastien VillemotReplace strmatch which is a deprecated function in MatlabUse strncmp instead, which has a different return type
http://www.mathworks.com/help/techdoc/ref/strmatch.html
Use strncmp instead, which has a different return type
http://www.mathworks.com/help/techdoc/ref/strmatch.html
https://git.dynare.org/Dynare/dynare/-/issues/140set_dynare_threads function fails on MATLAB < 7.22013-02-21T15:04:04ZSébastien Villemotset_dynare_threads function fails on MATLAB < 7.2This is because setenv() was introduced in MATLAB 7.2.
We need to find a workaround for older versions.
Currently Dynare crashes on these versions for that reason.
This is because setenv() was introduced in MATLAB 7.2.
We need to find a workaround for older versions.
Currently Dynare crashes on these versions for that reason.
4.2https://git.dynare.org/Dynare/dynare/-/issues/138Move Markov-Switching C-code under mex/sources, clarify the license2013-02-21T15:04:16ZSébastien VillemotMove Markov-Switching C-code under mex/sources, clarify the licenseAnd possibly give a better name to the module than "swz".
And possibly give a better name to the module than "swz".
4.3https://git.dynare.org/Dynare/dynare/-/issues/137remove occurences of mexErrMsgTxt() in all MEX files2013-02-21T15:04:16ZSébastien Villemotremove occurences of mexErrMsgTxt() in all MEX filesThis function throws a C++ exception, which is not handled correctly by MinGW for 64-bit (at the current time).
It appears that the benefits of using MinGW on Windows 64 are greater than the inconvenience of not using that function.
In case of error, MEX files should print a meaningful message with mexPrintf(), and then return control to MATLAB (with return()). A new output argument of the MEX file should be dedicated to informing MATLAB of the error condition (the output argument can be 0 in case of success, 1 in case of error). The MATLAB code should check that argument, and in case of failure should run "error('MEX failed')" to interrupt the execution of the code.
Note that it is still possible to use C++ exceptions inside the MEX function (as is currently done in k_order_perturbation), so that all error conditions can be catched by the top-level mexFunction().
This function throws a C++ exception, which is not handled correctly by MinGW for 64-bit (at the current time).
It appears that the benefits of using MinGW on Windows 64 are greater than the inconvenience of not using that function.
In case of error, MEX files should print a meaningful message with mexPrintf(), and then return control to MATLAB (with return()). A new output argument of the MEX file should be dedicated to informing MATLAB of the error condition (the output argument can be 0 in case of success, 1 in case of error). The MATLAB code should check that argument, and in case of failure should run "error('MEX failed')" to interrupt the execution of the code.
Note that it is still possible to use C++ exceptions inside the MEX function (as is currently done in k_order_perturbation), so that all error conditions can be catched by the top-level mexFunction().
4.2https://git.dynare.org/Dynare/dynare/-/issues/136complete implementation of "shock_decomposition"2016-04-15T07:45:56ZSébastien Villemotcomplete implementation of "shock_decomposition"add options for grouping shocks together and for choosing the set of parameters to be used
add options for grouping shocks together and for choosing the set of parameters to be used
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/131histval is broken in models with lag > 12013-09-30T09:24:22ZSébastien Villemothistval is broken in models with lag > 1initialization doesn't take auxiliary variables into account
initial matrix has wrong dimension
initialization doesn't take auxiliary variables into account
initial matrix has wrong dimension
4.2https://git.dynare.org/Dynare/dynare/-/issues/132forecast has a bug in models with lag > 12013-02-21T15:05:28ZSébastien Villemotforecast has a bug in models with lag > 14.2https://git.dynare.org/Dynare/dynare/-/issues/130Console mode2013-02-21T15:05:28ZSébastien VillemotConsole modeAdd an option to the dynare command for the console mode. This option may be called "console", "terminal" or "term", if used options_.console_mode would be set to 1 and graphical waitbars are replaced by text waitbars. The matlab code is ready (ie one can write options_.console_mode=1; in the mod file before the estimation command), Sébastien only needs to add something in the preprocessor.
Add an option to the dynare command for the console mode. This option may be called "console", "terminal" or "term", if used options_.console_mode would be set to 1 and graphical waitbars are replaced by text waitbars. The matlab code is ready (ie one can write options_.console_mode=1; in the mod file before the estimation command), Sébastien only needs to add something in the preprocessor.
4.2https://git.dynare.org/Dynare/dynare/-/issues/129Give more explicit error messages for purely backward/forward models2013-02-21T15:05:28ZSébastien VillemotGive more explicit error messages for purely backward/forward modelsSee for example:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2769
See for example:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2769
https://git.dynare.org/Dynare/dynare/-/issues/126Include Dynare++'s "dynare_simul.m" in the Dynare package2013-02-21T15:05:27ZSébastien VillemotInclude Dynare++'s "dynare_simul.m" in the Dynare package4.2https://git.dynare.org/Dynare/dynare/-/issues/128Fix derivatives of STEADY_STATE operator w.r.t. parameters in dynamic model2013-02-21T15:05:28ZSébastien VillemotFix derivatives of STEADY_STATE operator w.r.t. parameters in dynamic modelThe fix is to add a new input argument to the params_deriv file, which would contain the derivatives of the steady state w.r.t. parameters (it is the responsibility of the caller to provide them).
The fix is to add a new input argument to the params_deriv file, which would contain the derivatives of the steady state w.r.t. parameters (it is the responsibility of the caller to provide them).
4.2https://git.dynare.org/Dynare/dynare/-/issues/127Output 2nd derivatives of static model when doing identification2013-02-21T15:05:27ZSébastien VillemotOutput 2nd derivatives of static model when doing identificationThis is necessary for global identification.
The code for 2nd static derivatives already exists (used for planner_objective).
This is necessary for global identification.
The code for 2nd static derivatives already exists (used for planner_objective).
4.3https://git.dynare.org/Dynare/dynare/-/issues/125fix nograph option in forecast instruction2013-02-21T15:05:27ZSébastien Villemotfix nograph option in forecast instruction4.2https://git.dynare.org/Dynare/dynare/-/issues/123add external_function to the Reference Manual2013-02-21T15:05:27ZSébastien Villemotadd external_function to the Reference Manual4.2https://git.dynare.org/Dynare/dynare/-/issues/124write additional documentation for 3rd order2013-02-21T15:05:27ZSébastien Villemotwrite additional documentation for 3rd order- mention use_dll in order option of stoch_simul in Reference Manual
- document the output variables of 3rd order (on the Wiki?)
- mention use_dll in order option of stoch_simul in Reference Manual
- document the output variables of 3rd order (on the Wiki?)
4.2https://git.dynare.org/Dynare/dynare/-/issues/122Lower and upper bounds on priors used for two purposes2015-10-10T19:29:47ZSébastien VillemotLower and upper bounds on priors used for two purposesThe p3 and p4 parameters of estimated_params are currently used for two distinct purposes:
- specifying the domain of definition of the prior (uniform, generalized beta and gamma)
- restricting the optimization for the posterior mode on a sub-domain of the definition of the prior
This double usage of the same values is confusing, and makes some cases impossible to describe in a MOD file (example: restricting the optimization on a subdomain of the interval of a uniform).
The fix is probably to distinguish these two usages in the MOD file by introducing a new syntax for restricting the optimization, and reflecting that change in the M code.
The p3 and p4 parameters of estimated_params are currently used for two distinct purposes:
- specifying the domain of definition of the prior (uniform, generalized beta and gamma)
- restricting the optimization for the posterior mode on a sub-domain of the definition of the prior
This double usage of the same values is confusing, and makes some cases impossible to describe in a MOD file (example: restricting the optimization on a subdomain of the interval of a uniform).
The fix is probably to distinguish these two usages in the MOD file by introducing a new syntax for restricting the optimization, and reflecting that change in the M code.
https://git.dynare.org/Dynare/dynare/-/issues/121Revert example MOD files in user guide to mode_compute=42013-02-21T15:05:27ZSébastien VillemotRevert example MOD files in user guide to mode_compute=4The estimation examples in the user guide are not behaving nice with mode_compute=4, because of the non-deterministic nature of estimation. Many users were confused because on some runs, the example were failing because the hessian at the mode was not definite positive.
As a quick fix, the mode_compute option was changed to 6 in 4ec5016e5fed4d51e4ac987c1e8f4bcc85f3148f and 7b59c012b992387c2cc11ab5dd5a8175051cce79.
The problem is that the examples are now a lot slower than before.
We should revert back to mode_compute=4 when #85 is fixed and we have a way to fix the seed.
The estimation examples in the user guide are not behaving nice with mode_compute=4, because of the non-deterministic nature of estimation. Many users were confused because on some runs, the example were failing because the hessian at the mode was not definite positive.
As a quick fix, the mode_compute option was changed to 6 in 4ec5016e5fed4d51e4ac987c1e8f4bcc85f3148f and 7b59c012b992387c2cc11ab5dd5a8175051cce79.
The problem is that the examples are now a lot slower than before.
We should revert back to mode_compute=4 when #85 is fixed and we have a way to fix the seed.
4.3https://git.dynare.org/Dynare/dynare/-/issues/119Add boost/math (and possibly others) to the configure script for MEX files2013-02-21T15:05:27ZSébastien VillemotAdd boost/math (and possibly others) to the configure script for MEX files4.2https://git.dynare.org/Dynare/dynare/-/issues/1201st order coefficients reported by k-order DLL are not the same than Dynare++2013-02-21T15:05:27ZSébastien Villemot1st order coefficients reported by k-order DLL are not the same than Dynare++Reproducible on a model sent by Dario Caldara.
Reproducible on a model sent by Dario Caldara.
https://git.dynare.org/Dynare/dynare/-/issues/118Build system for SWZ DLL fails under Cygwin2013-02-21T15:05:27ZSébastien VillemotBuild system for SWZ DLL fails under CygwinThe problem comes from the GSL: the package shipped with Cygwin does not link with MATLAB DLLs, which are compiled with MinGW even under Cygwin.
The solution is probably to use a GSL compiled for MinGW:
http://gnuwin32.sourceforge.net/packages/gsl.htm
The problem comes from the GSL: the package shipped with Cygwin does not link with MATLAB DLLs, which are compiled with MinGW even under Cygwin.
The solution is probably to use a GSL compiled for MinGW:
http://gnuwin32.sourceforge.net/packages/gsl.htm
4.2https://git.dynare.org/Dynare/dynare/-/issues/117IRF: document the way they are computed at order 2 and 32013-02-21T15:05:27ZSébastien VillemotIRF: document the way they are computed at order 2 and 34.3https://git.dynare.org/Dynare/dynare/-/issues/114IRF: add an option to limit the exogenous shocked in the computations2013-02-21T15:05:27ZSébastien VillemotIRF: add an option to limit the exogenous shocked in the computations4.3https://git.dynare.org/Dynare/dynare/-/issues/112Metropolis: add the possibility for the user to give an arbitrary matrix for ...2013-11-05T16:17:59ZSébastien VillemotMetropolis: add the possibility for the user to give an arbitrary matrix for the variance of the jump proposalFeature suggested by Fabio Canova at the Dynare Conference 2010.
Feature suggested by Fabio Canova at the Dynare Conference 2010.
https://git.dynare.org/Dynare/dynare/-/issues/110Implement block decomposition for stochastic models2013-02-21T15:05:27ZSébastien VillemotImplement block decomposition for stochastic modelsThis can be very useful for some models.
For example, the BoE has a model with bond prices with a horizon of 10 years ahead (i.e. 40 periods). The bond prices do not feedback into the core of the macro model, so the pricing equations are purely forward.
At order 3, Dynare is currently at pains to solve the model. The block decomposition would dramatically improve performance here.
This can be very useful for some models.
For example, the BoE has a model with bond prices with a horizon of 10 years ahead (i.e. 40 periods). The bond prices do not feedback into the core of the macro model, so the pricing equations are purely forward.
At order 3, Dynare is currently at pains to solve the model. The block decomposition would dramatically improve performance here.
4.3https://git.dynare.org/Dynare/dynare/-/issues/109adapt model_steady_state for deterministic simulations2013-02-21T15:05:27ZSébastien Villemotadapt model_steady_state for deterministic simulations- how to call <modfile>_steadystate.m for initial or terminal values?
- how to set steadystate values for exogenous variables in model_steady_state?
- how to call <modfile>_steadystate.m for initial or terminal values?
- how to set steadystate values for exogenous variables in model_steady_state?
4.3https://git.dynare.org/Dynare/dynare/-/issues/113Metropolis: add adaptive hybrid MCMC2016-03-24T13:10:34ZSébastien VillemotMetropolis: add adaptive hybrid MCMCSee Ingvar Strid & Paolo Giordani & Robert Kohn “Adaptive hybrid MCMC for
DSGE models” (2010) presented at the Dynare Conference 2010.
See Ingvar Strid & Paolo Giordani & Robert Kohn “Adaptive hybrid MCMC for
DSGE models” (2010) presented at the Dynare Conference 2010.
https://git.dynare.org/Dynare/dynare/-/issues/111Add the possibility to solve underdetermined models2016-06-10T13:15:48ZSébastien VillemotAdd the possibility to solve underdetermined modelsWhen the Blanchard-Kahn conditions are not satisfied because the model is underdetermined, it is possible to select a solution among the infinity of solutions, provided we impose more restrictions.
We can implement the solution of Lubik and Schorfheide, “Testing for Indeterminacy:An Application to U.S. Monetary Policy” (AER, 2004), see http://ideas.repec.org/p/jhu/papers/480.html
When the Blanchard-Kahn conditions are not satisfied because the model is underdetermined, it is possible to select a solution among the infinity of solutions, provided we impose more restrictions.
We can implement the solution of Lubik and Schorfheide, “Testing for Indeterminacy:An Application to U.S. Monetary Policy” (AER, 2004), see http://ideas.repec.org/p/jhu/papers/480.html
https://git.dynare.org/Dynare/dynare/-/issues/107In a MOD file, comments located on the same line than a native MATLAB instruc...2013-02-21T15:05:26ZSébastien VillemotIn a MOD file, comments located on the same line than a native MATLAB instruction are not filtered outAt least if they are of the C form (/\* */) or C++ form (//).
Of course the MATLAB comments (%) will not create problems.
At least if they are of the C form (/\* */) or C++ form (//).
Of course the MATLAB comments (%) will not create problems.
4.2https://git.dynare.org/Dynare/dynare/-/issues/108Create an interface for DSGE-Var2013-02-21T15:05:26ZSébastien VillemotCreate an interface for DSGE-VarNeeds an option of estimation, which takes a value:
- if the value is numeric, means that the weight of the DSGE prior is calibrated to that value
- if the value is a string, means that this weight is estimated as this given parameter
Also needs an option for number of lags.
See: http://www.dynare.org/DynareWiki/DsgeVar
Needs an option of estimation, which takes a value:
- if the value is numeric, means that the weight of the DSGE prior is calibrated to that value
- if the value is a string, means that this weight is estimated as this given parameter
Also needs an option for number of lags.
See: http://www.dynare.org/DynareWiki/DsgeVar
4.2https://git.dynare.org/Dynare/dynare/-/issues/104Add option pruning2013-02-21T15:06:42ZSébastien VillemotAdd option pruningAdd option pruning in stoch_simul for second order simulations. The preprocessor should set options_.pruning equal to one if pruning option is used. The preprocessor should issue a warning if pruning and k_order_solver are used simultaneously (pruning is not available in dynare_simul_).
Add option pruning in stoch_simul for second order simulations. The preprocessor should set options_.pruning equal to one if pruning option is used. The preprocessor should issue a warning if pruning and k_order_solver are used simultaneously (pruning is not available in dynare_simul_).
4.2https://git.dynare.org/Dynare/dynare/-/issues/106Document prior distributions2016-06-10T13:16:23ZSébastien VillemotDocument prior distributionsThe document from Stéphane is probably the one to use.
It should be added to the doc/ subdirectory, then to the build-system and to the packaging.
The document from Stéphane is probably the one to use.
It should be added to the doc/ subdirectory, then to the build-system and to the packaging.
https://git.dynare.org/Dynare/dynare/-/issues/105Support normcdf(), asinh(), acosh(), atanh() for USE_DLL+MSVC combination2013-02-21T15:05:26ZSébastien VillemotSupport normcdf(), asinh(), acosh(), atanh() for USE_DLL+MSVC combinationThis would be particularly useful for Windows/64 users, since they don't have the Cygwin option.
This would be particularly useful for Windows/64 users, since they don't have the Cygwin option.
https://git.dynare.org/Dynare/dynare/-/issues/103bug in dealing with <fname>_steadystate.m functions that modify parameters2013-02-21T15:06:42ZSébastien Villemotbug in dealing with <fname>_steadystate.m functions that modify parametersThe changes to M_.params introduced in <fname>_steadystate.m functions are not taken into accounts by calling functions that obtain M_ as argument and not as global variable.
Need to add
M_.params = evalin('base','M_.params');
after each call to <fname>_steadystate.m function
The changes to M_.params introduced in <fname>_steadystate.m functions are not taken into accounts by calling functions that obtain M_ as argument and not as global variable.
Need to add
M_.params = evalin('base','M_.params');
after each call to <fname>_steadystate.m function
4.2https://git.dynare.org/Dynare/dynare/-/issues/102forecast graphs in manual2013-03-18T09:17:06ZSébastien Villemotforecast graphs in manualThe graphs of forecasts with uncertainty about the parameters have changed but we didn't modify the user manual and the user guide
The graphs of forecasts with uncertainty about the parameters have changed but we didn't modify the user manual and the user guide
4.4https://git.dynare.org/Dynare/dynare/-/issues/101Preprocessor crashes when some dynamic variables appear only in unused model ...2013-02-21T15:06:42ZSébastien VillemotPreprocessor crashes when some dynamic variables appear only in unused model local variablesSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2592
The fix is probably to add calls to ExprNode::collectVariables() on model local variables from DynamicModel::computeDerivIDs()
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2592
The fix is probably to add calls to ExprNode::collectVariables() on model local variables from DynamicModel::computeDerivIDs()
https://git.dynare.org/Dynare/dynare/-/issues/100Add exception for degenerate beta prior.2013-02-21T15:06:42ZSébastien VillemotAdd exception for degenerate beta prior.If the declared prior expectation and standard deviation are equal to 0.5, the prior density is not defined because in this special case the parameters \alpha and \beta are zero. We should add an exception for this case.
If the declared prior expectation and standard deviation are equal to 0.5, the prior density is not defined because in this special case the parameters \alpha and \beta are zero. We should add an exception for this case.
4.2https://git.dynare.org/Dynare/dynare/-/issues/99too many graphs crash Matlab2013-02-21T15:06:41ZSébastien Villemottoo many graphs crash MatlabA large number of busy graphs (34 in my example) crash Matlab r2010a under Linux 64-bit
I still need to upload the example to test it in different versions of Matlab
A large number of busy graphs (34 in my example) crash Matlab r2010a under Linux 64-bit
I still need to upload the example to test it in different versions of Matlab
4.2https://git.dynare.org/Dynare/dynare/-/issues/98Implement STEADY_STATE operator with USE_DLL and bytecode options2013-02-21T15:06:41ZSébastien VillemotImplement STEADY_STATE operator with USE_DLL and bytecode optionshttps://git.dynare.org/Dynare/dynare/-/issues/96Problem with struct2local.m2013-02-21T15:06:41ZSébastien VillemotProblem with struct2local.mThe function struct2local.m doesn't work as expected when a function exists in the path with the same name than a variable to be unpacked.
After the call to struct2local, MATLAB gives precedence to the function over the local variable.
This behavior is apparently in contradiction with the precedence rules described on:
http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f10-60956.html#
However it is present on most versions of MATLAB, and should be taken as a normal behavior of MATLAB.
A possible fix is to drop the use of struct2local, and to unpack structures by hand.
The function struct2local.m doesn't work as expected when a function exists in the path with the same name than a variable to be unpacked.
After the call to struct2local, MATLAB gives precedence to the function over the local variable.
This behavior is apparently in contradiction with the precedence rules described on:
http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f10-60956.html#
However it is present on most versions of MATLAB, and should be taken as a normal behavior of MATLAB.
A possible fix is to drop the use of struct2local, and to unpack structures by hand.
https://git.dynare.org/Dynare/dynare/-/issues/97estimation with mode_compute=6 fails under Octave2013-02-21T15:06:41ZSébastien Villemotestimation with mode_compute=6 fails under OctaveThe reason is that the code uses a graphical waitbar, which is not available under Octave.
The fix is to replace it by a text waitbar.
See the following thread:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2531
The reason is that the code uses a graphical waitbar, which is not available under Octave.
The fix is to replace it by a text waitbar.
See the following thread:
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2531
https://git.dynare.org/Dynare/dynare/-/issues/94Remove obsolete code dealing with more than one lead and/or one lag2013-02-21T15:06:41ZSébastien VillemotRemove obsolete code dealing with more than one lead and/or one lagIn the resolution of stochastic models, this code is no longer necessary since the preprocessor removes any lead and lag of more than one.
But this code should be kept in the deterministic case, since the preprocessor doesn't do the transformation.
In the resolution of stochastic models, this code is no longer necessary since the preprocessor removes any lead and lag of more than one.
But this code should be kept in the deterministic case, since the preprocessor doesn't do the transformation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/93Replace functions deprecated in MATLAB 7.10 (R2010a)2013-02-21T15:06:41ZSébastien VillemotReplace functions deprecated in MATLAB 7.10 (R2010a)Among others, the following functions are deprecated in MATLAB 7.10 (R2010a), but still work:
isstr, setstr, str2mat, strread, strvcat, textread
Every occurrence of these functions should be replaced in the M-files and in the preprocessor, for compatibility with future versions of MATLAB.
See http://www.mathworks.com/access/helpdesk/help/techdoc/rn/br_bpq8-1.html#bsdnyvb-1 for their replacements.
Among others, the following functions are deprecated in MATLAB 7.10 (R2010a), but still work:
isstr, setstr, str2mat, strread, strvcat, textread
Every occurrence of these functions should be replaced in the M-files and in the preprocessor, for compatibility with future versions of MATLAB.
See http://www.mathworks.com/access/helpdesk/help/techdoc/rn/br_bpq8-1.html#bsdnyvb-1 for their replacements.
4.2https://git.dynare.org/Dynare/dynare/-/issues/92Add erf() and normpdf() as primitives2013-02-21T15:06:41ZSébastien VillemotAdd erf() and normpdf() as primitives4.2https://git.dynare.org/Dynare/dynare/-/issues/89Add bsxfun function for old versions of matlab.2013-02-21T15:06:41ZSébastien VillemotAdd bsxfun function for old versions of matlab.Built in function bsxfun appeared in matlab version 7.4. Dynare (with matlab's version < 7.4) may crash (depending on what the user is doing) because this function is missing.
We have first to add an m file (in the missing subdirectory) doing the same job as bsxfun. This workaround will be at the cost of computing efficiency (built in bsxfun is very fast). So, if we really want to be compatible with all the versions of matlab since 7.0 (or 6.5.1 I can't remember) we have to write a mex file (it should be possible to use the source of the octave's built-in).
Built in function bsxfun appeared in matlab version 7.4. Dynare (with matlab's version < 7.4) may crash (depending on what the user is doing) because this function is missing.
We have first to add an m file (in the missing subdirectory) doing the same job as bsxfun. This workaround will be at the cost of computing efficiency (built in bsxfun is very fast). So, if we really want to be compatible with all the versions of matlab since 7.0 (or 6.5.1 I can't remember) we have to write a mex file (it should be possible to use the source of the octave's built-in).
4.2https://git.dynare.org/Dynare/dynare/-/issues/91Univariate smoother with missing observations needs corrections.2013-02-21T15:06:41ZSébastien VillemotUnivariate smoother with missing observations needs corrections.The last block (if nargout>7) is wrong and cause dynare to crash. Variable iF is not defined in this function (should be Fi i think). There is also a problem with the selection matrix Z.
The last block (if nargout>7) is wrong and cause dynare to crash. Variable iF is not defined in this function (should be Fi i think). There is also a problem with the selection matrix Z.
https://git.dynare.org/Dynare/dynare/-/issues/90Inconsistency between Brooks & Gelman convergence diagnostics and mh_drop2013-02-21T15:06:41ZSébastien VillemotInconsistency between Brooks & Gelman convergence diagnostics and mh_dropBrooks & Gelman convergence diagnostics are not always consistent with the way the posterior moments are computed. These diagnostics are built discarding half of the simulations at each step. By default the posterior moments are computed discarding half of the mcmc draws... But if the user changes the value of mh_drop, 100*mh_drop percent of the mcmc draws will be discarded when computing posterior moments, while the convergence diagnostics still discard the first half of the simulation at each step.
The fix is to replace .5 by options_.mh_drop in McMCDiagnostics_core.m
Brooks & Gelman convergence diagnostics are not always consistent with the way the posterior moments are computed. These diagnostics are built discarding half of the simulations at each step. By default the posterior moments are computed discarding half of the mcmc draws... But if the user changes the value of mh_drop, 100*mh_drop percent of the mcmc draws will be discarded when computing posterior moments, while the convergence diagnostics still discard the first half of the simulation at each step.
The fix is to replace .5 by options_.mh_drop in McMCDiagnostics_core.m
4.2https://git.dynare.org/Dynare/dynare/-/issues/88smoother is computed for auxiliary variables2013-02-21T15:06:41ZSébastien Villemotsmoother is computed for auxiliary variablesThe smoother is currently computed for all variables, including auxiliary variables.
The smoother should be computed only for requested variables
The smoother is currently computed for all variables, including auxiliary variables.
The smoother should be computed only for requested variables
https://git.dynare.org/Dynare/dynare/-/issues/87fix order of integration in univariate filter/smoother2014-01-22T13:21:56ZSébastien Villemotfix order of integration in univariate filter/smoother4.2https://git.dynare.org/Dynare/dynare/-/issues/86check matrix power used in forecast2013-02-21T15:06:41ZSébastien Villemotcheck matrix power used in forecasttaking large matrix power in forecast step of the Kalman smoother routines is expensive, but probably more accurate than recursive multiplications.
- investigate more accuracy issue
- factorise matrix decomposition for matrix power
taking large matrix power in forecast step of the Kalman smoother routines is expensive, but probably more accurate than recursive multiplications.
- investigate more accuracy issue
- factorise matrix decomposition for matrix power
4.3https://git.dynare.org/Dynare/dynare/-/issues/83persistent variables must be cleared at the beginning of a Dynare run2013-02-21T15:06:40ZSébastien Villemotpersistent variables must be cleared at the beginning of a Dynare runpersistent variables in *.m files trigger hard to understand errors if the user run successively two different *.mod files with 'noclearall' option.
Whenever a function uses persistent variables, there should be an explicit initialize option and not rely on empty persistent variables as, for example, priordens.m currently does.
persistent variables in *.m files trigger hard to understand errors if the user run successively two different *.mod files with 'noclearall' option.
Whenever a function uses persistent variables, there should be an explicit initialize option and not rely on empty persistent variables as, for example, priordens.m currently does.
4.3https://git.dynare.org/Dynare/dynare/-/issues/84normcdf() doesn't work with k_order2013-02-21T15:06:40ZSébastien Villemotnormcdf() doesn't work with k_orderThe reason is that normcdf() is not translated into C code.
It can easily be fixed using the erf() function available from the math library.
The reason is that normcdf() is not translated into C code.
It can easily be fixed using the erf() function available from the math library.
https://git.dynare.org/Dynare/dynare/-/issues/81bicgstab function does not exist in Octave 3.02013-02-21T15:07:22ZSébastien Villemotbicgstab function does not exist in Octave 3.0bicgstab function exists in both MATLAB and Octave 3.2, but not in Octave 3.0.
This break option stack_solve_algo=3 under Octave 3.0.
The fix is probably to backport the function from Octave 3.2 to Octave 3.0, and add in the matlab/missing/ subdir.
bicgstab function exists in both MATLAB and Octave 3.2, but not in Octave 3.0.
This break option stack_solve_algo=3 under Octave 3.0.
The fix is probably to backport the function from Octave 3.2 to Octave 3.0, and add in the matlab/missing/ subdir.
https://git.dynare.org/Dynare/dynare/-/issues/79Some Dynare++ tests fail2016-03-23T17:26:01ZSébastien VillemotSome Dynare++ tests failSome unit tests of Dynare++ fail:
- in the integ library
- in the kord library
Moreover, the kord tests take a VERY long time.
We need to check with Ondra how to fix these tests.
Some unit tests of Dynare++ fail:
- in the integ library
- in the kord library
Moreover, the kord tests take a VERY long time.
We need to check with Ondra how to fix these tests.
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/80Crashes of Dynare++ under Windows2013-02-21T15:07:22ZSébastien VillemotCrashes of Dynare++ under WindowsThe Dynare++ binary for Windows crashes on some test MOD-files (test.mod, test3.mod), while it runs fine with others (judd.mod, example1.mod).
This problem seems to beem Windows-specific, it does not appear under Linux.
The Dynare++ binary for Windows crashes on some test MOD-files (test.mod, test3.mod), while it runs fine with others (judd.mod, example1.mod).
This problem seems to beem Windows-specific, it does not appear under Linux.
https://git.dynare.org/Dynare/dynare/-/issues/78Problem with derivatives of power function at point zero2013-02-21T15:07:22ZSébastien VillemotProblem with derivatives of power function at point zeroThere is currently a problem with the derivatives of the power function f(x)=x^p^ at the point x=0.
The power function f(x)=x^p^ well defined for x>0 and for any p, since f(x)=e^p*ln(x)^.
The domain of definition of this function can be extended to x=0 with the following rules when p>0:
- f(0)=0
- f is differentiable k times at x=0, where k is the integer part of p, and f'^k^=0
And when p is an strictly positive integer, the function is differentiable at any order, and its derivative at zero is zero.
When p is a constant, the preprocessor computes the right value of the derivatives at x=0, using simplifications rules.
But when p is a parameter, the preprocessor will not give the right value for integer values of p.
Currently the derivation rule is applied by the preprocessor, the k-th derivative of f(x) is equal to:
p_(p-1)_..._(p-k+1)_x^p-k^
So when p is an integer, the (p+1)-th derivative computed at x=0 will give a NaN (0 times infinity), while it ought to be zero.
This problem typically arises in models with adjustment costs where the curvature (the exponent) of the cost is a integer parameter, and the cost is zero at steady state.
The solution is probably to create, in the preprocessor, a new operator called "derivative of power function at order k". This operator would output a code like that in the M-file:
dxp=deriv(x,p,k) % The k-th derivative of x^p
if abs(x) < 1e-12 && (p > 0) && (abs(p - round(p)) < 1e-12 && k >= p
dxp = 0;
else
dxp = x^(p-k);
for i=1:k-1
dxp = dxp*p;
p = p-1;
end
end
There is currently a problem with the derivatives of the power function f(x)=x^p^ at the point x=0.
The power function f(x)=x^p^ well defined for x>0 and for any p, since f(x)=e^p*ln(x)^.
The domain of definition of this function can be extended to x=0 with the following rules when p>0:
- f(0)=0
- f is differentiable k times at x=0, where k is the integer part of p, and f'^k^=0
And when p is an strictly positive integer, the function is differentiable at any order, and its derivative at zero is zero.
When p is a constant, the preprocessor computes the right value of the derivatives at x=0, using simplifications rules.
But when p is a parameter, the preprocessor will not give the right value for integer values of p.
Currently the derivation rule is applied by the preprocessor, the k-th derivative of f(x) is equal to:
p_(p-1)_..._(p-k+1)_x^p-k^
So when p is an integer, the (p+1)-th derivative computed at x=0 will give a NaN (0 times infinity), while it ought to be zero.
This problem typically arises in models with adjustment costs where the curvature (the exponent) of the cost is a integer parameter, and the cost is zero at steady state.
The solution is probably to create, in the preprocessor, a new operator called "derivative of power function at order k". This operator would output a code like that in the M-file:
dxp=deriv(x,p,k) % The k-th derivative of x^p
if abs(x) < 1e-12 && (p > 0) && (abs(p - round(p)) < 1e-12 && k >= p
dxp = 0;
else
dxp = x^(p-k);
for i=1:k-1
dxp = dxp*p;
p = p-1;
end
end
4.2https://git.dynare.org/Dynare/dynare/-/issues/76Under Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "ms...2013-02-21T15:07:22ZSébastien VillemotUnder Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "msvc" optionThe fix is easy: in ModFile.cc, use MATLAB's error() command instead of exiting the preprocessor when neither "cygwin" nor "msvc" is specified under MATLAB/Windows.
The fix is easy: in ModFile.cc, use MATLAB's error() command instead of exiting the preprocessor when neither "cygwin" nor "msvc" is specified under MATLAB/Windows.
https://git.dynare.org/Dynare/dynare/-/issues/77provide all solve_algo for all representations of the model2013-02-21T15:07:22ZSébastien Villemotprovide all solve_algo for all representations of the modelFor the moment, only some combinations of block, bytecode and stack_solve_algo are available. Allow for the possibility to use all the algorithms for all model representation.
For the moment, only some combinations of block, bytecode and stack_solve_algo are available. Allow for the possibility to use all the algorithms for all model representation.
4.3https://git.dynare.org/Dynare/dynare/-/issues/74Variance decomposition gives dummy results in the presence of non-stationary ...2013-02-21T15:07:22ZSébastien VillemotVariance decomposition gives dummy results in the presence of non-stationary varsIn the attached MOD file, the variance decomposition is clearly bogus: some lines don't sum to 100% (some percentages are even negative).
The problem does not occur with Dynare 4.0.4. This is probably related to the fact that this model contains a non-stationary variable. The file th_autocovariances.m has changed between versions 4.0.4 and 4.1.0 with respect to the treatment of stationary variables.
Also note that the problem does not come from the fact that some shocks are switched off (with a zero variance) in the attached MOD file. Activating all the shocks still gives dummy results.
In the attached MOD file, the variance decomposition is clearly bogus: some lines don't sum to 100% (some percentages are even negative).
The problem does not occur with Dynare 4.0.4. This is probably related to the fact that this model contains a non-stationary variable. The file th_autocovariances.m has changed between versions 4.0.4 and 4.1.0 with respect to the treatment of stationary variables.
Also note that the problem does not come from the fact that some shocks are switched off (with a zero variance) in the attached MOD file. Activating all the shocks still gives dummy results.
https://git.dynare.org/Dynare/dynare/-/issues/722nd and 3rd order approximation of purely backward and forward models2016-06-10T12:51:41ZSébastien Villemot2nd and 3rd order approximation of purely backward and forward models- need to write specialized code for 2nd and 3rd order approximation of purely backward and forward models
- need to write specialized code for 2nd and 3rd order approximation of purely backward and forward models
https://git.dynare.org/Dynare/dynare/-/issues/70USE_DLL option affected by the timestamp directory bug of Octave 3.22013-02-21T15:07:21ZSébastien VillemotUSE_DLL option affected by the timestamp directory bug of Octave 3.24.1https://git.dynare.org/Dynare/dynare/-/issues/71rplot command fails on model with no lags2013-02-21T15:07:22ZSébastien Villemotrplot command fails on model with no lags4.1https://git.dynare.org/Dynare/dynare/-/issues/69Update or remove code for multithreaded DLL using OpenMP2013-02-21T15:07:21ZSébastien VillemotUpdate or remove code for multithreaded DLL using OpenMPConcerns directories:
mex/sources/threads
matlab/threads
and files:
matlab/dynare_config.m
mex/sources/build_matlab_multithread.m
Removed from 4.1 branch in r3259
Concerns directories:
mex/sources/threads
matlab/threads
and files:
matlab/dynare_config.m
mex/sources/build_matlab_multithread.m
Removed from 4.1 branch in r3259
4.2https://git.dynare.org/Dynare/dynare/-/issues/68Option stack_solve_algo with values 2, 3 and 4 are not working properly2013-02-21T15:07:21ZSébastien VillemotOption stack_solve_algo with values 2, 3 and 4 are not working properlySee the following files in tests/block_bytecode:
fs2000_bicgstab.mod
fs2000_gmres.mod
fs2000_optpath.mod
ramst_a.mod
In the first two files, computation succeeds but gives wrong results. In the last two files, MATLAB fails with an error.
See the following files in tests/block_bytecode:
fs2000_bicgstab.mod
fs2000_gmres.mod
fs2000_optpath.mod
ramst_a.mod
In the first two files, computation succeeds but gives wrong results. In the last two files, MATLAB fails with an error.
4.1https://git.dynare.org/Dynare/dynare/-/issues/66Document the fast deterministic simulations in the reference manual2013-02-21T15:07:21ZSébastien VillemotDocument the fast deterministic simulations in the reference manualAt least we should incoporate the new options described on:
http://www.dynare.org/DynareWiki/FastDeterministicSimulationAndSteadyStateComputation
At least we should incoporate the new options described on:
http://www.dynare.org/DynareWiki/FastDeterministicSimulationAndSteadyStateComputation
4.1https://git.dynare.org/Dynare/dynare/-/issues/67Bug in gamrnd (prior_draw)2013-02-21T15:07:21ZSébastien VillemotBug in gamrnd (prior_draw)For some types of gamma samples, like
mean=1.5 and std=0.25,
which implies a=36, b= 0.0417
the gamrnd dynare routine provides wrong values (too high), always rejected since the values are always above the upper bound.
For some types of gamma samples, like
mean=1.5 and std=0.25,
which implies a=36, b= 0.0417
the gamrnd dynare routine provides wrong values (too high), always rejected since the values are always above the upper bound.
https://git.dynare.org/Dynare/dynare/-/issues/65Second order derivatives w.r.t. parameters2013-02-21T15:07:21ZSébastien VillemotSecond order derivatives w.r.t. parametersIn identification analysis, for the computation of the Jacobian of typical optimization problems like moment matching (limited information).
In identification analysis, for the computation of the Jacobian of typical optimization problems like moment matching (limited information).
4.2https://git.dynare.org/Dynare/dynare/-/issues/64Fix USE_DLL option at order 22013-02-21T15:07:21ZSébastien VillemotFix USE_DLL option at order 2Currently the MEX returns a hessian made of 3 columns (sparse representation: two columns for indices, one column for values).
A call to sparse() function needs to be added in dr1.m when USE_DLL option is used. Maybe a field options_.use_dll should be added by the preprocessor to facilitate the test in dr1.m.
Currently the MEX returns a hessian made of 3 columns (sparse representation: two columns for indices, one column for values).
A call to sparse() function needs to be added in dr1.m when USE_DLL option is used. Maybe a field options_.use_dll should be added by the preprocessor to facilitate the test in dr1.m.
4.1https://git.dynare.org/Dynare/dynare/-/issues/63new option instrument2013-02-21T15:07:21ZSébastien Villemotnew option instrumentDocument the new option "instrument" for ramsey_policy in reference manual and write wiki page on using *_steadystate.m file with ramsey_policy
Document the new option "instrument" for ramsey_policy in reference manual and write wiki page on using *_steadystate.m file with ramsey_policy
4.3https://git.dynare.org/Dynare/dynare/-/issues/62error message from histval syntax2013-02-21T15:07:53ZSébastien Villemoterror message from histval syntaxif one writes wrongly
histval;
y = 1;
end;
instead of
histval;
y(0)=1;
end;
there is no error message with the line number where the error occurs
Note also that the reference manual is missleading because the (lag) doesn't appear in the syntax
if one writes wrongly
histval;
y = 1;
end;
instead of
histval;
y(0)=1;
end;
there is no error message with the line number where the error occurs
Note also that the reference manual is missleading because the (lag) doesn't appear in the syntax
https://git.dynare.org/Dynare/dynare/-/issues/61error message for histval syntax2013-02-21T15:07:53ZSébastien Villemoterror message for histval syntaxif one writes wrongly
histval;
y = 1;
end;
instead of
histval;
y,1;
end;
there is no error message with the line number where the error occurs
if one writes wrongly
histval;
y = 1;
end;
instead of
histval;
y,1;
end;
there is no error message with the line number where the error occurs
4.1https://git.dynare.org/Dynare/dynare/-/issues/60Fix memory leaks in k_order_perturbation DLL2013-02-21T15:07:53ZSébastien VillemotFix memory leaks in k_order_perturbation DLLhttps://git.dynare.org/Dynare/dynare/-/issues/59add errors to print_info.m2013-02-21T15:07:53ZSébastien Villemotadd errors to print_info.minfo(1) == 43 (covariance matrix of shocks is not positive definite) should be added to print_info.m
We need to check that all error numbers that can be present in info(1) are taken care of. We need to check with grep info *.m
info(1) == 43 (covariance matrix of shocks is not positive definite) should be added to print_info.m
We need to check that all error numbers that can be present in info(1) are taken care of. We need to check with grep info *.m
4.3https://git.dynare.org/Dynare/dynare/-/issues/58Implement constrained parameters for osr2016-05-10T15:14:03ZSébastien VillemotImplement constrained parameters for osrhttps://git.dynare.org/Dynare/dynare/-/issues/57Translate or remove auxiliary variables in output of commands2013-02-21T15:07:53ZSébastien VillemotTranslate or remove auxiliary variables in output of commands4.1https://git.dynare.org/Dynare/dynare/-/issues/56Faster smoother for large models2013-02-21T15:07:53ZSébastien VillemotFaster smoother for large models4.2https://git.dynare.org/Dynare/dynare/-/issues/55Finalize the generic parallelization system2013-02-21T15:07:52ZSébastien VillemotFinalize the generic parallelization systemSee http://www.dynare.org/DynareWiki/ParallelDynare for the remain subtasks.
See http://www.dynare.org/DynareWiki/ParallelDynare for the remain subtasks.
4.2https://git.dynare.org/Dynare/dynare/-/issues/54Add hp_filter2013-02-21T15:07:52ZSébastien VillemotAdd hp_filterOnly theoretical hp filterd moments are available in the current version. We need to add a general function for hp filtering time series and call this new function when displaying simulated moements (with option hp filter).
Only theoretical hp filterd moments are available in the current version. We need to add a general function for hp filtering time series and call this new function when displaying simulated moements (with option hp filter).
4.2https://git.dynare.org/Dynare/dynare/-/issues/53Clean up and speed up simult_.m2013-02-21T15:07:52ZSébastien VillemotClean up and speed up simult_.m4.2https://git.dynare.org/Dynare/dynare/-/issues/52stoch_simul + hpfilter2013-02-21T15:07:52ZSébastien Villemotstoch_simul + hpfilterstoch_simul (order 1 and theoretical moments) crashes with hpfilter options.
stoch_simul (order 1 and theoretical moments) crashes with hpfilter options.
4.1https://git.dynare.org/Dynare/dynare/-/issues/50Add dynare_simul_ to build_matlab.m2013-02-21T15:07:52ZSébastien VillemotAdd dynare_simul_ to build_matlab.m4.1https://git.dynare.org/Dynare/dynare/-/issues/51Add new command to create dynamic model file with given options, when there i...2016-06-10T13:12:43ZSébastien VillemotAdd new command to create dynamic model file with given options, when there is no simul/stoch_simul...https://git.dynare.org/Dynare/dynare/-/issues/49User guide: update chapter on installation of Dynare2013-02-21T15:07:52ZSébastien VillemotUser guide: update chapter on installation of Dynare4.1https://git.dynare.org/Dynare/dynare/-/issues/48Incorrect treatment of log-linear transformation for purely backward looking ...2013-02-21T15:07:52ZSébastien VillemotIncorrect treatment of log-linear transformation for purely backward looking modelsIn dr1.m, log-linear test and the log-linear transformation of the model ghx and ghu matrices at line 449 are not reached for a purely backward looking model, because of a return statement at line 266
In dr1.m, log-linear test and the log-linear transformation of the model ghx and ghu matrices at line 449 are not reached for a purely backward looking model, because of a return statement at line 266
4.1