November 2009 - Dev - dynare.org

Re: [DynareDev] Fw: [Trac] #60: Fix memory leaks in k_order_perturbation DLL
by Sébastien Villemot 03 Dec '09

03 Dec '09

Le lundi 30 novembre 2009 à 17:50 +0000, G. Perendia a écrit : > Is there any more info on this issue? Please see my comment associated to the #60 issue on the trac system. Please answer there if you want to continue the discussion. -- Sébastien Villemot

3 6

Fw: disclyap_fast issue
by G. Perendia 30 Nov '09

30 Nov '09

Dear Michel It seems that disclyap_fast is not returning results for good reasons whilst Dynare solver lyapunov_symm still returns some acceptable results which may or may not result in incorrect estimates. The problem with NAN was debugged from C++ version of DsgeLikelihood as I was trying to use fs2000k model and the non-pos-def with fs2000a (though either of which models are not the most suitable anyway) . The pos-def issue occurred in Matlab Dynare as I was running disclyap_fast with check option, something not currently imposed in either C++ DsgeLikelihood nor in lyapunov_symm. But I wander what we should do in such situations if it occur in general - stick to disclyap_fast diagnosis and return penalty from DsgeLikelihood in case results are NAN (which seems adequate solution at least for time being) or poss. change C++ lyapunov solver? Also, - shall we check if Pstar is positive definite and also abandon with penalty or continue as is done at the moment? Best regards George ----- Original Message ----- From: "joe pearlman" <j.pearlman(a)londonmet.ac.uk> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> Sent: Thursday, November 26, 2009 2:38 PM Subject: Re: disclyap_fast issue > > Dear George > > there is quite obviously an eigenvalue of 1 in the T matrix, so the > Lyapunov matrix cannot posibly converge! > > Joe > > G. Perendia wrote: > > > > > Dear Joe > > > > I have encountered a problem with disclyap_fast returning NAN matrix > > when another Dynare solver returns still suitable results for KF. Please > > see the enclosed file giving input and outputs. > > > > Do you have any suggestions on how to overcome such issue? > > > > Best regards > > > > George

3 4

Follow up on Markov Switching meeting
by Sébastien Villemot 26 Nov '09

26 Nov '09

Hi, Following our meeting on Markov Switching code: * Tao, Junior, Karl and Stéphane L. are now subscribed to the list of Dynare developers * On the wiki, I renamed the page on SWZ options, and created a page with the proposal for the interface (incorporating some of the changes that we discussed during the meeting). See: http://www.dynare.org/DynareWiki/MarkovSwitchingOptions http://www.dynare.org/DynareWiki/MarkovSwitchingInterface * I made a change to the preprocessor: using sbvar or ms_sbvar without a model block should now work Best, -- Sébastien Villemot

3 2

[Trac] #57: Translate or remove auxiliary variables in output of commands
by Trac Dynare 25 Nov '09

25 Nov '09

#57: Translate or remove auxiliary variables in output of commands --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: enhancement | Status: new Priority: major | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/57> Dynare <http://www.dynare.org> The Dynare project

1 1

[Trac] #36: Write a Wiki page on the various incompatibilities accross MATLAB versions
by Trac Dynare 23 Nov '09

23 Nov '09

#36: Write a Wiki page on the various incompatibilities accross MATLAB versions ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: Type: feature | Status: new Priority: minor | Milestone: Component: Documentation | Version: Keywords: | ---------------------------+------------------------------------------------ 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/ -- Ticket URL: <https://www.dynare.org/trac/ticket/36> Dynare <http://www.dynare.org> The Dynare project

1 1

printf in Vector and GeneralMatrix
by G. Perendia 20 Nov '09

20 Nov '09

Hi I intend to change printf() calls in the <object>print() functions of some of the Dynare++ Sylv exceptions and Vector and GeneralMatrix to mexPrintf()and use following to switch between printf and mexPrintf() #ifdef MATLAB #include "mex.h" #else #define mexPrintf printf #endif Is that OK or will this cause any problems? Best regards George

3 5

General Matrix Issue
by G. Perendia 19 Nov '09

19 Nov '09

Hi Sebastien (et all) 1) Whilst trying to use one of already present public functions in sylv/General Matrix.h/cpp (multRightTrans) in DsgeLikelihood, the multiplication was crashing and I realised that there appear to be an issue with two private, underlying functions (gemm_partial_left and gemm_partial_right). They use a (fixed?) private static variable int md_length for number of rows/columns for partial-copy of the host matrix. The variable is in .cpp defined to be 32 i.e. int GeneralMatrix::md_length = 32; and has no apparent mechanism to be dynamically modified so, as it is, it appears that those functions may work only for matrices of specific size(s) - However, I may have missed something and someone may be able to throw some light how is md_length adjusted and/or properly used? 2) The gemm_partial_left and gemm_partial_right are used by the following public functions: multRight, multRightTrans multLeft multLeftTrans And then, all those are used on a couple of places by the (so far unused and untested) C++ Diffuse Kalman filters and in the kalman utils library TSUtils::correctDefinitness (also used by Diffuse Kalman filters) and, as well, by few classes in the sylv library, e.g. MultRight is then used by other classes such as QuasiTriangularZero and SchurDecompZero multiply-constructors. One would need to investigate further whether if any of those functions are being used currently by any of the current Dynare applications or any of the GeneralMatrix children classes (and there are few of those in tl_library) and, if needed poss. carefully modify their behaviour and/or use of md_length. Does anyone know of their direct use by other Dynare apps so far and/or has any experience of them? I also looked into Dynare++ and KroneckerProd but they do not appear there (other than within the sylv library) In meantime, for DsgeLikelihood I may need to write an alternative way of multRightTrans untill this issue is resolved. Should I log this as a bug/issue in Track and write an alternative multRightTranspose for DsgeLikelihood or investigate the issue straight on? Best regards George

3 6

Re: [DynareDev] General Matrix Issue
by G. Perendia 18 Nov '09

18 Nov '09

PS: 3) Glancing at the code it appear to me that the 2 gemm_partial_* functions were an attempt to optimise multiplication by doing it in parts but seem to be incomplete (unfinished?) and their four calling function (mult*) may need to be rewritten. I think that may be poss. done in a very simple, quick (but working) way, replacing calls to gemm_partial_*, far less effort than investigating their possible (mis)use or trying to fix their partial multiplication. ----- Original Message ----- From: G. Perendia To: List for Dynare developers Sent: Wednesday, November 18, 2009 2:16 PM Subject: Re: [DynareDev] General Matrix Issue Thanks Michel 1) My out-of-the-box Dynere build does not work smoothly and it is rather slow and cumbersome on my cygwin system. 2) However, trying to build (my local) k_order_pert test executable or the DLL both fail if gemm_partial_* are not present in GeneralMatrix.cpp as the linker fails to resolve the link from multRight/Left* to them so I guess Dynare++ would not build too although the problematic functions may not be called during the processing. Best regards George ----- Original Message ----- From: Michel Juillard To: List for Dynare developers Sent: Wednesday, November 18, 2009 10:48 AM Subject: Re: [DynareDev] General Matrix Issue Hi 1. Are you able to build whole of Dynare out of the box with configure and make files? 2. if that is the case, remove the two problematic functions and see what doesn' t build If it is only the Kalman filter just fix the functions Best Michel Juillard On Nov 18, 2009, at 11:32, "G. Perendia" <george(a)perendia.orangehome.co.uk> wrote: Hi Sebastien (et all) 1) Whilst trying to use one of already present public functions in sylv/General Matrix.h/cpp (multRightTrans) in DsgeLikelihood, the multiplication was crashing and I realised that there appear to be an issue with two private, underlying functions (gemm_partial_left and gemm_partial_right). They use a (fixed?) private static variable int md_length for number of rows/columns for partial-copy of the host matrix. The variable is in .cpp defined to be 32 i.e. int GeneralMatrix::md_length = 32; and has no apparent mechanism to be dynamically modified so, as it is, it appears that those functions may work only for matrices of specific size(s) - However, I may have missed something and someone may be able to throw some light how is md_length adjusted and/or properly used? 2) The gemm_partial_left and gemm_partial_right are used by the following public functions: multRight, multRightTrans multLeft multLeftTrans And then, all those are used on a couple of places by the (so far unused and untested) C++ Diffuse Kalman filters and in the kalman utils library TSUtils::correctDefinitness (also used by Diffuse Kalman filters) and, as well, by few classes in the sylv library, e.g. MultRight is then used by other classes such as QuasiTriangularZero and SchurDecompZero multiply-constructors. One would need to investigate further whether if any of those functions are being used currently by any of the current Dynare applications or any of the GeneralMatrix children classes (and there are few of those in tl_library) and, if needed poss. carefully modify their behaviour and/or use of md_length. Does anyone know of their direct use by other Dynare apps so far and/or has any experience of them? I also looked into Dynare++ and KroneckerProd but they do not appear there (other than within the sylv library) In meantime, for DsgeLikelihood I may need to write an alternative way of multRightTrans untill this issue is resolved. Should I log this as a bug/issue in Track and write an alternative multRightTranspose for DsgeLikelihood or investigate the issue straight on? Best regards George _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev ---------------------------------------------------------------------------- _______________________________________________ Dev mailing list Dev(a)dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

1 0

Re: [DynareDev] [Trac] #2: Add finite time variance decomposition
by Trac Dynare 12 Nov '09

12 Nov '09

#2: Add finite time variance decomposition ---------------------------+------------------------------------------------ Reporter: sebastien | Owner: stepan Type: feature | Status: closed Priority: major | Milestone: 4.1 Component: Core M-files | Version: Resolution: fixed | Keywords: ---------------------------+------------------------------------------------ Changes (by sebastien): * status: assigned => closed * resolution: => fixed -- Ticket URL: <https://www.dynare.org/trac/ticket/2#comment:2> Dynare <http://www.dynare.org> The Dynare project

1 0

Re: [DynareDev] partial info + estimation
by Sébastien Villemot 09 Nov '09

09 Nov '09

Hi George, Le samedi 07 novembre 2009 à 10:17 +0000, G. Perendia a écrit : > I will need a number reserved for Part info kalman_algo. I currently use a > literal PartInfoKF set to 11. The status of kalman_algo is somewhat hybrid: it is both an option that can be modified by the user (yet undocumented), and an intermediary result which is modified by the Matlab routines. I don't yet fully understand how this works, so I let Michel or Stéphane answer if this creates a problem. In the future, we should probably create a variable in oo_ which will store the modified value of kalman_algo; values in options_ should not be modified. Michel and Stéphane: by the way, what is the status of dsge_posterior_kernel.m? This function is not called by any other M-function nor by the preprocessor. > PS: Yesterday I uploaded the changes to Part info branch needed for PI > estimation (5 modified and 6 renamed files to avoid name conflicts) but I > did not get root(a)dynare.org email info. Your commit was registered and I got the email. I don't know why you didn't get the email, I suppose it was filtered by your anti-spam. Best -- Sébastien Villemot

3 2