dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-02-21T15:06:42Zhttps://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/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/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_.us...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/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/mis...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/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 b...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...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/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/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.2