Yes, this is correct. The modification of the ordering of variables (order_var) is internal to dr1 and its results, but isn't present in *_dynamic.m (or .c) and doesn't concern dynare++ nor the perturbation.dll project. It is only important when comparing results with the Matlab version of Dynare
Best
Michel
G. Perendia wrote:
Hi Sebastien
Thanks,
- your precise definition than I think matches pretty well my first
description (and have I already assumed that organisation though I wrote wrong number of row) though, just to clarify:
each of m=jcols blocks than has m=jcols columns- where m=jcols= number of columns of jacobian where
m= jcols = nEndo+nsPred+nsForw+nExog.
so that each of the m=jcols blocks is containing all of : gxx, gxu=gux and guu's,
Are the variables (and the 2nd derivative blocks) then in the order of their specification in the model, i.e. as they appear in jacobian too, with the exogenous shocks at the end of each block.?
- Yes, I do confirm that perturbation.dll expects plain, full 2D matrices
from the .dll for both, the jacobian and the hessian.
Best regards
George
----- Original Message ----- From: "Sébastien Villemot" sebastien.villemot@ens.fr To: dev@dynare.org Sent: Thursday, April 09, 2009 11:23 AM Subject: Re: [DynareDev] Hessian
Hi George,
"G. Perendia" george@perendia.orangehome.co.uk a écrit :
Can you please confirm how is the 2D matrix Hessian that is coming from <model>_dynamic.c/dll created and organised (and, similarly the sparse hessian from the matlab .m version),
The hessian matrix is a 2D array. If we denote by n the number of lines of the Jacobian (i.e. number of equations of the model), and by m the number of columns of the Jacobian (i.e. number of dynamic endogenous + exogenous), then the Hessian is a n by m^2 array.
The 2nd derivative of equation i=1..n with respect to variables j=1..m and k=1..m is stored in element (n, j+m*(k-1)) of the Hessian. By symmetry, it is also in element (n, k+m*(j-1)).
Otherwise, I have now fixed the bug that you reported earlier. Now, the dynamic DLL file returns a sparse array for the Hessian, so that dr1.m no longer fails at the place which you mentionned.
For your own purposes, I have understood that you need a full hessian (instead of a sparse one). Can you confirm this? If it is the case, then I shall implement the "pertub_dll" option (as suggested by Michel), so that the preprocessor gives you a full hessian in that case.
Best,