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

Sent: Wednesday, November 18, 2009 2:16 PM

Subject: Re: [DynareDev] General Matrix Issue

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.

----- Original Message -----

From: Michel Juillard

Sent: Wednesday, November 18, 2009 10:48 AM

Subject: Re: [DynareDev] General Matrix Issue

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

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