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@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@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

------------------------------------------------------------------------------

_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

Le mercredi 18 novembre 2009 à 14:34 +0000, Sébastien Villemot a écrit :

On my cygwin installation, I can build everything out of the box (Dynare, Dynare++, MEX for MATLAB and Octave) without any tweaking.

Or to be more precise, I applied the tweaks described on the wiki page... http://www.dynare.org/DynareWiki/BuildingDynareFromSource

Dear Michel

Thanks, you are right, the problem is not with md_length, and sorry for taking your time.

After more detailed analysis I realised that the four mult* functions calling the gemm_partial_* do work correctly but only if the supplied matrix is a matching square one which does not change the shape/size of the in-place host/target matrix.

I was unsuccessfully trying to use multRightTrans by supplying a (matching) rectangular matrix (i.e. for [RQ]*R' where [RQ] was the host target) which attempts to change the size and shape of the host/target, something those functions are not (yet) built to cater for.

I now use a different, a constructor function for the [RQ]*R' multiplication.

Best regards

George ----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, November 18, 2009 9:15 PM Subject: Re: [DynareDev] General Matrix Issue

Dear George,

I had time to look briefly to gemm_partial_left and gemm_partial_right and I don't understand what is troubling you. What I understand is the these functions perform multiplication "in place" by doing the mutliplication block by block. Each block has 32 columns (resp rows). This may not always be optimal, but I don't see that a constant md_length should make this code crash. Maybe you saw something that I didn't.

Best

Michel

G. Perendia 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@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev

---

Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev