Dev

dev@dynare.org

3402 discussions

[Trac] #84: normcdf() doesn't work with k_order
by Trac Dynare 23 Feb '10

23 Feb '10

#84: normcdf() doesn't work with k_order --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/84> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #89: Add bsxfun function for old versions of matlab.
by Trac Dynare 23 Feb '10

23 Feb '10

#89: Add bsxfun function for old versions of matlab. --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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). -- Ticket URL: <https://www.dynare.org/trac/ticket/89> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #62: error message from histval syntax
by Trac Dynare 23 Feb '10

23 Feb '10

#62: error message from histval syntax --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- 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 -- Ticket URL: <https://www.dynare.org/trac/ticket/62> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #90: Inconsistency between Brooks & Gelman convergence diagnostics and mh_drop
by Trac Dynare 18 Feb '10

18 Feb '10

#90: Inconsistency between Brooks & Gelman convergence diagnostics and mh_drop --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: new Priority: trivial | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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 -- Ticket URL: <https://www.dynare.org/trac/ticket/90> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #81: bicgstab function does not exist in Octave 3.0
by Trac Dynare 17 Feb '10

17 Feb '10

#81: bicgstab function does not exist in Octave 3.0 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Core M-files | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/81> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #76: Under Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "msvc" option
by Trac Dynare 17 Feb '10

17 Feb '10

#76: Under Octave/Windows, with USE_DLL, Dynare should not require "cygwin" or "msvc" option --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/76> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] [Trac] #80: Crashes of Dynare++ under Windows
by Trac Dynare 17 Feb '10

17 Feb '10

1 0

Re: [DynareDev] [Trac] #80: Crashes of Dynare++ under Windows
by Trac Dynare 17 Feb '10

17 Feb '10

#80: Crashes of Dynare++ under Windows ------------------------+--------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: major | Milestone: Component: Dynare++ | Version: 4.1.0 Resolution: | Keywords: ------------------------+--------------------------------------------------- Comment(by sebastien): This is a compiler issue. When compiled with MinGW GCC 4.4.0 with Dwarf-2 exceptions (bundled with Octave/MinGW 3.2.3), the problem occurs. When compiled with MinGW GCC 4.4.1 with Sjlj exceptions (from TDM - http://www.tdragon.net/recentgcc/ ), the problem does not occur. This should be taken into account when producing Dynare++ in the next Dynare release. Note: For installing TDM GCC, use the bundled installer (check gfortran, uncheck add to the PATH), this will install MinGW in c:\MinGW\. Then run the two commands for compilation (from Octave's MSYS): {{{ export PATH=$PATH:/c/MinGW/bin:/c/Octave/3.2.3_gcc4.4.0/bin ./configure CPPFLAGS="-I/home/user/boost_1_41_0" LDFLAGS="-L/c/Octave/3.2.3_gcc4.4.0/lib" --disable-octave }}} The MinGW with Dwarf-2 exceptions is probably only mandatory for Octave MEX files (this needs to be checked). -- Ticket URL: <https://www.dynare.org/trac/ticket/80#comment:1> Dynare <http://www.dynare.org> The Dynare project

1 0

bsxfun
by George Perendia 17 Feb '10

17 Feb '10

Hi Running fs2000k2a.mod I encountered an error ??? Undefined command/function 'bsxfun'. Error in ==> disp_moments at 48 y = bsxfun(@minus, y, m); any ideas why bsxfun is missing or what was intended? -- Best regards George 07951415480

4 4

options_.diffuse_d
by Michel Juillard 15 Feb '10

15 Feb '10

When we implemented the diffuse filter/smoother, we used options_.diffuse_d to record the number of iterations spent in the diffuse part of the filter. 1) in the filter functions in kalman/likelihood, it is not used anymore except in univariate_diffuse_kalman_filter_corr.m. It is still present in the old (and not yet replaced) smoother functions. 2) in the multivariate case, diffuse_d can be interpreted as the number of periods for which we use the diffuse step. In the univariate case, diffuse_d is incremented inside the variable loop and can't be interpreted this way 3) when there is no missing observations, the number of period iterations spent in the diffuse step is equal to the highest order of integration of the variables of the model. The field name in oo_.smoother reflect this. But hen missing observations are present, its interpretation is much less clear. 4) In the past, we wanted to monitor diffuse_d, to make sure that it didn't change because of numerical issues. Now that we are using the Schur transformation of the transition equation, the numerical instability seems to have disappeared. All that to say that my inclination would be for dropping oo_.diffuse_d entirely. What do you think? Ondra, I know that this will create problems for GPM and its current infrastructure code. But I think that we should handle this problem in a different way, taking into account the number of periods with missing observations at the beginning of the sample and the order of intergation of the GPM model (== 1) that we know by construction. All the best, Michel

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev