dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2014-01-22T13:21:56Zhttps://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.1