Dev November 2010

dev@dynare.org

4 participants
64 discussions

[Trac] #78: Problem with derivatives of power function at point zero
by Trac Dynare 17 Dec '10

17 Dec '10

#78: Problem with derivatives of power function at point zero --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- 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 (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 }}} -- Ticket URL: <https://www.dynare.org/trac/ticket/78> Dynare <http://www.dynare.org> The Dynare project

1 7

[Trac] #154: Change build process to make libslicot optional on Mac OS X
by Trac Dynare 13 Dec '10

13 Dec '10

#154: Change build process to make libslicot optional on Mac OS X --------------------------------------+------------------------------------- Reporter: houtanb | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.2 Component: Build system / Packaging | Version: Keywords: | --------------------------------------+------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/154> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #73: The macroprocessor fails when the file ends with @#endif or @#endfor without a new line at the EOF
by Trac Dynare 06 Dec '10

06 Dec '10

#73: The macroprocessor fails when the file ends with @#endif or @#endfor without a new line at the EOF --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: Component: Preprocessor | Version: 4.1.0 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/73> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #99: too many graphs crash Matlab
by Trac Dynare 03 Dec '10

03 Dec '10

#99: too many graphs crash Matlab --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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 -- Ticket URL: <https://www.dynare.org/trac/ticket/99> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #53: Clean up and speed up simult_.m
by Trac Dynare 18 Nov '10

18 Nov '10

#53: Clean up and speed up simult_.m --------------------------+------------------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/53> Dynare <http://www.dynare.org> The Dynare project

1 2

[Trac] #153: parameters with lead or lag
by Trac Dynare 18 Nov '10

18 Nov '10

#153: parameters with lead or lag --------------------------+------------------------------------------------- Reporter: michel | Owner: sebastien Type: bug | Status: new Priority: major | Milestone: Component: Preprocessor | Version: 4.1.3 Keywords: | --------------------------+------------------------------------------------- In model, a parameter followed by a lead or a lag construct doesn't trigger an error, but M_.maximum_lead or M_.maximum_lag is affected if this lead or lag > 2. -- Ticket URL: <https://www.dynare.org/trac/ticket/153> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #40: Test M_.params at the top of the main functions.
by Trac Dynare 17 Nov '10

17 Nov '10

#40: Test M_.params at the top of the main functions. --------------------------+------------------------------------------------- Reporter: stepan | Owner: Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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). -- Ticket URL: <https://www.dynare.org/trac/ticket/40> Dynare <http://www.dynare.org> The Dynare project

1 3

[Trac] #103: bug in dealing with <fname>_steadystate.m functions that modify parameters
by Trac Dynare 15 Nov '10

15 Nov '10

#103: bug in dealing with <fname>_steadystate.m functions that modify parameters --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: major | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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 -- Ticket URL: <https://www.dynare.org/trac/ticket/103> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #140: set_dynare_threads function fails on MATLAB < 7.2
by Trac Dynare 15 Nov '10

15 Nov '10

#140: set_dynare_threads function fails on MATLAB < 7.2 --------------------------+------------------------------------------------- Reporter: sebastien | Owner: Type: bug | Status: new Priority: critical | Milestone: 4.2 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- 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. -- Ticket URL: <https://www.dynare.org/trac/ticket/140> Dynare <http://www.dynare.org> The Dynare project

1 2

Dynare internal documentation
by Michel Juillard 15 Nov '10

15 Nov '10

I have uploaded to GIT the beginning of an internal documentation for Dynare. It is written in emacs org-mode and export easily to HTML, Latex and PDF. It is located in ./doc/internals/dynare-internals.org Sébastien is going to include it in the automatic build system of Dynare and it will be automatically updated from GIT on the web site (or maybe rather on the Wiki as it is just the beginning of something). Please, comment on the format that can surely be improved upon and suggest practical alternatives. Don't hesitate to contribute as well. Best, Michel

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev November 2010