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)
- 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?
- 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