dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2016-06-10T13:16:23Zhttps://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/85Estimation is not deterministic: a seed should be explictly given to random n...2013-04-10T13:42:53ZSébastien VillemotEstimation is not deterministic: a seed should be explictly given to random number generatorCurrently MOD files doing estimation are not deterministic: different runs of the same MOD files don't give the same results, since the seed for random number generator is not the same accross runs.
The easy way to fix that is to set the seed in dynare.m. There would be a default value for the seed, or it could be changed through an option/command.
A more subtle way would be to have a seed reset at the top of every major function (estimation, stoch_simul).
More details on the following wiki page:
http://www.dynare.org/DynareWiki/FixingRandomseed
We need to decide which way is the best.
Currently MOD files doing estimation are not deterministic: different runs of the same MOD files don't give the same results, since the seed for random number generator is not the same accross runs.
The easy way to fix that is to set the seed in dynare.m. There would be a default value for the seed, or it could be changed through an option/command.
A more subtle way would be to have a seed reset at the top of every major function (estimation, stoch_simul).
More details on the following wiki page:
http://www.dynare.org/DynareWiki/FixingRandomseed
We need to decide which way is the best.
https://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/82prior_analysis and posterior_analysis commands broken2013-02-21T15:07:22ZSébastien Villemotprior_analysis and posterior_analysis commands brokenThe prior_analysis and posterior_analysis commands are broken: the calling sequence generated by the preprocessor doesn't match the calling sequence of the MATLAB function...
Their documentation in the ref. manual also needs updating.
The prior_analysis and posterior_analysis commands are broken: the calling sequence generated by the preprocessor doesn't match the calling sequence of the MATLAB function...
Their documentation in the ref. manual also needs updating.
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/75Fix command "calib" or remove it2013-02-21T15:07:22ZSébastien VillemotFix command "calib" or remove itThe "calib" command (and its associated command "calib_var") are recognized by the preprocessor, but are probably not working, and are not documented in the reference manual.
This should be fixed, or the commands be removed.
The "calib" command (and its associated command "calib_var") are recognized by the preprocessor, but are probably not working, and are not documented in the reference manual.
This should be fixed, or the commands be removed.
4.2https://git.dynare.org/Dynare/dynare/-/issues/73The macroprocessor fails when the file ends with @#endif or @#endfor without ...2013-02-21T15:07:22ZSébastien VillemotThe macroprocessor fails when the file ends with @#endif or @#endfor without a new line at the EOF4.2https://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.1https://git.dynare.org/Dynare/dynare/-/issues/46Update examples on the website2013-02-21T15:07:52ZSébastien VillemotUpdate examples on the websiteMost MOD files examples distributed on the website don't work with Dynare 4. They were designed for Dynare 3. We regularly get posts on the forum by newcomers to Dynare who don't understand why these examples fail.
We should update them to Dynare 4.
Most MOD files examples distributed on the website don't work with Dynare 4. They were designed for Dynare 3. We regularly get posts on the forum by newcomers to Dynare who don't understand why these examples fail.
We should update them to Dynare 4.
https://git.dynare.org/Dynare/dynare/-/issues/44The preprocessor segfaults on GIMF model with "block" option2013-02-21T15:08:29ZSébastien VillemotThe preprocessor segfaults on GIMF model with "block" optionAs of r3244, the preprocessor is now able to normalize the static and dynamic models (for the static model it is a singular normalization, because of the presence of unit root shocks).
But after the normalization, the preprocessor segfaults.
I can't post the MOD file here, so ask for it.
As of r3244, the preprocessor is now able to normalize the static and dynamic models (for the static model it is a singular normalization, because of the presence of unit root shocks).
But after the normalization, the preprocessor segfaults.
I can't post the MOD file here, so ask for it.
4.1https://git.dynare.org/Dynare/dynare/-/issues/45Implement resid() with "block" option without "bytecode"2013-02-21T15:07:52ZSébastien VillemotImplement resid() with "block" option without "bytecode"https://git.dynare.org/Dynare/dynare/-/issues/43bug in 2nd order approximation2013-02-21T15:08:29ZSébastien Villemotbug in 2nd order approximationChange in the order of declaration of endogenous variables affects 2nd order approximation. Bug reported by Huixin 9/21
Change in the order of declaration of endogenous variables affects 2nd order approximation. Bug reported by Huixin 9/21
4.1https://git.dynare.org/Dynare/dynare/-/issues/42Fix problem of order 2 with leads of two or more2013-02-21T15:08:29ZSébastien VillemotFix problem of order 2 with leads of two or moreFixed by commits r3002 and r3026.
Fixed by commits r3002 and r3026.
4.1https://git.dynare.org/Dynare/dynare/-/issues/40Test M_.params at the top of the main functions.2013-02-21T15:08:28ZSébastien VillemotTest M_.params at the top of the main functions.simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN).
simul, stoch_simul, steady, ... should display a warning when some of the parameters are not initialized (that is when some of the elements of M_.params are NaN).
4.2https://git.dynare.org/Dynare/dynare/-/issues/41bug in resid.m that reset initial values when used after ENDVAL2013-02-21T15:08:28ZSébastien Villemotbug in resid.m that reset initial values when used after ENDVALresid shouldn't modify oo_ or any global variables
Maybe it should check against <fname>_static rather than <fname>_dynamic
resid shouldn't modify oo_ or any global variables
Maybe it should check against <fname>_static rather than <fname>_dynamic
4.1https://git.dynare.org/Dynare/dynare/-/issues/37Automatic generation of _steadystate.m file2019-12-05T15:58:38ZSébastien VillemotAutomatic generation of _steadystate.m fileThe idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block.
This would be particularly useful for estimating models for which the analytical form of the steady state is known.
The idea is that the preprocessor would create a _steadystate.m file, using the (symbolic) initializations given in the initval block.
This would be particularly useful for estimating models for which the analytical form of the steady state is known.
4.2https://git.dynare.org/Dynare/dynare/-/issues/38Allow k-order and estimation DLL to use bytecode for the model evaluation2016-06-10T13:10:36ZSébastien VillemotAllow k-order and estimation DLL to use bytecode for the model evaluationCurrently, k-order DLL and estimation DLL only work with use_dll option.
This constraint could be easily relieved by calling the M-file of the model from within the DLL, using mexCallMATLAB().
For the bytecode, a similar trick could be done, provided that support is added for 2nd and 3rd order derivatives.
From the implementation side, the idea would be to create an super class of DynamicModelDll.
This change needs to be documented in the reference manual when implemented.
Currently, k-order DLL and estimation DLL only work with use_dll option.
This constraint could be easily relieved by calling the M-file of the model from within the DLL, using mexCallMATLAB().
For the bytecode, a similar trick could be done, provided that support is added for 2nd and 3rd order derivatives.
From the implementation side, the idea would be to create an super class of DynamicModelDll.
This change needs to be documented in the reference manual when implemented.
https://git.dynare.org/Dynare/dynare/-/issues/35Putting "shocks" before "endval" leads to wrong results2014-04-08T15:53:59ZSébastien VillemotPutting "shocks" before "endval" leads to wrong resultsIn a deterministic setup with both temporary and permanent shocks, the order of the shocks and endval blocks matter. Actually, putting shocks before endval leads to wrong results.
shocks uses set_shocks.m, which fills in oo_.exo_simul; the point is that, if endval has not been used, this structure is empty, so set_shocks fills it, at date of shocks, for ''all'' the exogenous, and using the ''initial'' steady state value.
When simul is finally called, it completes oo_.exo_simul with the ''final'' exogenous steady state, but only for those periods which have no temporary shocks. So at the dates with temporary shocks, the value of exogenous which are permanently shocked is wrong.
A quick fix is to forbid the use of shocks before endval.
A cleaner fix is to modify set_shocks.m so that it only sets values for the exogenous which are temporarily shocked, and leaves NaN for other exogenous. It would be simul's job to fill in the holes.
In a deterministic setup with both temporary and permanent shocks, the order of the shocks and endval blocks matter. Actually, putting shocks before endval leads to wrong results.
shocks uses set_shocks.m, which fills in oo_.exo_simul; the point is that, if endval has not been used, this structure is empty, so set_shocks fills it, at date of shocks, for ''all'' the exogenous, and using the ''initial'' steady state value.
When simul is finally called, it completes oo_.exo_simul with the ''final'' exogenous steady state, but only for those periods which have no temporary shocks. So at the dates with temporary shocks, the value of exogenous which are permanently shocked is wrong.
A quick fix is to forbid the use of shocks before endval.
A cleaner fix is to modify set_shocks.m so that it only sets values for the exogenous which are temporarily shocked, and leaves NaN for other exogenous. It would be simul's job to fill in the holes.
https://git.dynare.org/Dynare/dynare/-/issues/36Write a Wiki page on the various incompatibilities accross MATLAB versions2013-02-21T15:08:28ZSébastien VillemotWrite a Wiki page on the various incompatibilities accross MATLAB versionsThis wiki page should only document changes relevant to Dynare, in particular with respect to MEX files.
All MATLAB release notes since R14 are available on:
http://www.mathworks.com/access/helpdesk/help/techdoc/
This wiki page should only document changes relevant to Dynare, in particular with respect to MEX files.
All MATLAB release notes since R14 are available on:
http://www.mathworks.com/access/helpdesk/help/techdoc/
https://git.dynare.org/Dynare/dynare/-/issues/34Fix the dimension of oo_.mean.2013-02-21T15:08:28ZSébastien VillemotFix the dimension of oo_.mean.Depending on the situation (simulated moments or theoretical moments) oo_.mean is a column or a row vector.
Depending on the situation (simulated moments or theoretical moments) oo_.mean is a column or a row vector.
4.1https://git.dynare.org/Dynare/dynare/-/issues/33Correct bug in imcforecast.2013-02-21T15:08:28ZSébastien VillemotCorrect bug in imcforecast.The call to DsgeSmoother is buggy because of the missing observation new feature.
The call to DsgeSmoother is buggy because of the missing observation new feature.
4.1https://git.dynare.org/Dynare/dynare/-/issues/30Correct buggy mh_recover mode2013-02-21T15:08:28ZSébastien VillemotCorrect buggy mh_recover modeThe initialization of the mcmc and the number of simulations are wrong when there is only one mcmc chain.
The initialization of the mcmc and the number of simulations are wrong when there is only one mcmc chain.
4.1https://git.dynare.org/Dynare/dynare/-/issues/32Report MATLAB crashes on Linux/64 to Mathworks2013-02-21T15:08:28ZSébastien VillemotReport MATLAB crashes on Linux/64 to MathworksOn Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX).
See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB.
The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64.
As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on.
We need to report this to Mathworks.
On Linux, the 64-bits version of MATLAB crashes on some models with Dynare. The crash seems to occur with rather big models. It is reproducible, in the sense that the same code will always trigger the bug; but a small change in the code can sometimes make the crash disappear. Note that the crash is only triggered by M-files (no MEX).
See the attached "plouf.m" and "plouf_static.m". They are derived from preprocessor-generated files with the EAGLE model. The script "plouf.m" calls the function "plouf_static.m". Attached is the crash dump of MATLAB.
The crash is reproducible on MATLAB Linux/64, versions 7.5, 7.6 and 7.8. But it does not occur on MATLAB for Linux/32, Windows/32 and Windows/64.
As can be seen from the displayed marks which I have inserted, MATLAB crashes around line 131 of "plouf_static.m". More precisely, it seems to crash just after having computed the expression there. I can't understand exactly what's going on.
We need to report this to Mathworks.
https://git.dynare.org/Dynare/dynare/-/issues/28Define a syntax for bytecode generation and the various Newton solvers (for s...2013-02-21T15:08:59ZSébastien VillemotDefine a syntax for bytecode generation and the various Newton solvers (for steady and simul)4.1https://git.dynare.org/Dynare/dynare/-/issues/29bug with varexo_det2013-02-21T15:08:28ZSébastien Villemotbug with varexo_detSee wiki entry
See wiki entry
4.1https://git.dynare.org/Dynare/dynare/-/issues/26Nonlinear estimation2013-02-21T15:08:59ZSébastien VillemotNonlinear estimationhttps://git.dynare.org/Dynare/dynare/-/issues/27Finite element solution method2016-06-10T13:10:09ZSébastien VillemotFinite element solution methodFor the IMF.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/25Prototype of finite element method (ZLB)2013-02-21T15:08:58ZSébastien VillemotPrototype of finite element method (ZLB)For the IMF.
For the IMF.
4.3https://git.dynare.org/Dynare/dynare/-/issues/24Add Markov-Switching2013-02-21T15:08:58ZSébastien VillemotAdd Markov-SwitchingFor DSGE-net.
For DSGE-net.
4.3https://git.dynare.org/Dynare/dynare/-/issues/22Expand specification of priors (i.e. priors on relative variances between 2 s...2016-06-10T13:09:30ZSébastien VillemotExpand specification of priors (i.e. priors on relative variances between 2 shocks)For the IMF.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/23Add Estimation DLL2016-06-10T12:50:14ZSébastien VillemotAdd Estimation DLLFor DSGE-net.
For DSGE-net.
4.5https://git.dynare.org/Dynare/dynare/-/issues/20Create new Dynare web site (using Plone)2013-02-21T15:08:58ZSébastien VillemotCreate new Dynare web site (using Plone)https://git.dynare.org/Dynare/dynare/-/issues/18Clean-up, streamline and documente filter/smoother routines2013-02-21T15:08:58ZSébastien VillemotClean-up, streamline and documente filter/smoother routinesFor the IMF.
For the IMF.
4.3https://git.dynare.org/Dynare/dynare/-/issues/17Update user guide2016-06-10T13:08:22ZSébastien VillemotUpdate user guideFor DSGE-net.
For DSGE-net.
https://git.dynare.org/Dynare/dynare/-/issues/19Add tool to automatically write a stationary version of the model, given tren...2013-02-21T15:08:58ZSébastien VillemotAdd tool to automatically write a stationary version of the model, given trends supplied by userFor the IMF.
For the IMF.
4.2https://git.dynare.org/Dynare/dynare/-/issues/15Add order 3 derivatives in USE_DLL mode (for k-order)2013-02-21T15:08:58ZSébastien VillemotAdd order 3 derivatives in USE_DLL mode (for k-order)4.1https://git.dynare.org/Dynare/dynare/-/issues/16Reindent all source code (C++, M-files)2013-02-21T15:08:58ZSébastien VillemotReindent all source code (C++, M-files)4.1https://git.dynare.org/Dynare/dynare/-/issues/14Create a database of old and new example MOD files2013-02-21T15:09:15ZSébastien VillemotCreate a database of old and new example MOD filesFor DSGE-net.
Some thoughts on this are on the following page:
[http://www.dynare.org/DynareWiki/ExamplesDatabase]
The idea is to have a new "examples/" subdirectory in the SVN, with a bunch of MOD files running with the current version of Dynare.
For DSGE-net.
Some thoughts on this are on the following page:
[http://www.dynare.org/DynareWiki/ExamplesDatabase]
The idea is to have a new "examples/" subdirectory in the SVN, with a bunch of MOD files running with the current version of Dynare.
4.3https://git.dynare.org/Dynare/dynare/-/issues/13Add estimation with unexpected structural change2014-01-27T15:53:07ZSébastien VillemotAdd estimation with unexpected structural changeFor DSGE-net.
For DSGE-net.
https://git.dynare.org/Dynare/dynare/-/issues/12Compute temporary terms when using option block_mfs of steady2013-02-21T15:09:15ZSébastien VillemotCompute temporary terms when using option block_mfs of steady4.1https://git.dynare.org/Dynare/dynare/-/issues/11Allow for the possibility of using the bytecode representation of the model f...2013-02-21T15:09:15ZSébastien VillemotAllow for the possibility of using the bytecode representation of the model for any task4.2https://git.dynare.org/Dynare/dynare/-/issues/10Retrieve the source code for PDFs in user guide2020-03-12T17:12:34ZSébastien VillemotRetrieve the source code for PDFs in user guideWe should contact Tommaso about that issue.
We should contact Tommaso about that issue.
https://git.dynare.org/Dynare/dynare/-/issues/8Benchmarks with various BLAS libraries2016-06-10T13:06:07ZSébastien VillemotBenchmarks with various BLAS librariesWe should test the 5 options:
- reference BLAS
- generic ATLAS
- customized ATLAS
- generic OpenBLAS
- customized OpenBLAS
The tests should be performed on a few hardware and on a few interesting models. The results should be put on a Wiki page.
We should test the 5 options:
- reference BLAS
- generic ATLAS
- customized ATLAS
- generic OpenBLAS
- customized OpenBLAS
The tests should be performed on a few hardware and on a few interesting models. The results should be put on a Wiki page.
https://git.dynare.org/Dynare/dynare/-/issues/9Improve wiki page on coding guidelines2016-06-10T13:07:02ZSébastien VillemotImprove wiki page on coding guidelineshttp://www.dynare.org/DynareWiki/CodingStandards
We could add things like:
- no commented code (git already stores the history)
- no mexprintf
- use asserts
- write short functions
- pass-by-reference whenever possible
http://www.dynare.org/DynareWiki/CodingStandards
We could add things like:
- no commented code (git already stores the history)
- no mexprintf
- use asserts
- write short functions
- pass-by-reference whenever possible
https://git.dynare.org/Dynare/dynare/-/issues/5Integrate algorithm for TBC by Holden and Paetz (2012)2013-02-21T07:14:04ZSébastien VillemotIntegrate algorithm for TBC by Holden and Paetz (2012)Request by Stéphane Moyen.
Paper at http://www.tholden.org/files/zlb.pdf?attredirects=0
Apparently the code has been posted on the Dynare forums. It's therefore a matter of dealing with copyright/license issues and integrating it.
Request by Stéphane Moyen.
Paper at http://www.tholden.org/files/zlb.pdf?attredirects=0
Apparently the code has been posted on the Dynare forums. It's therefore a matter of dealing with copyright/license issues and integrating it.
4.4https://git.dynare.org/Dynare/dynare/-/issues/2Be more flexible about variable declarations2020-03-12T17:12:34ZSébastien VillemotBe more flexible about variable declarationsRequest by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
Request by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1Don't fail when initializing an unknown variable in initval2013-09-16T20:15:23ZSébastien VillemotDon't fail when initializing an unknown variable in initvalThis is a request from Pascal Jacquinot, in order to facilitate the development phase of a model.
This is a request from Pascal Jacquinot, in order to facilitate the development phase of a model.
4.5Houtan BastaniHoutan Bastani