PS: Please ignore the exceptions for matrix "a" and "1"s in the "Note" section below - i.e. all matrices and numbers are subject to the sign changes. On 20/10/2010 10:59, George Perendia wrote:
Thanks Sebastien
Removing the header file as you suggested allowed me to compile the mkoctfil package and the compiled qzcomplex.oct then provided nearly the same output as Matlab qz() does which, despite some differences, enables us to have the same results in Octave and Matlab for the PI package saddlepath condition without substantially changing our PI code, but for few lines, e.g. using.
if exist('OCTAVE_VERSION') [a b q z]=qzcomplex(G0pi,G1pi); q=q'; else [a b q z]=qz(G0pi,G1pi); end
This is something we could not achieve with any of the available calls to Octave QZ(), with its differnt forms, options and params.
Can we then please include C Sims' qzcomplex.oct package and build it into our releases for Octave PI users because it saves us from changing our code further?
Note: I.e. whilst sparse "a" matrices seem fully identical and all other matrices from qzcomplex and qz Matlab have identical numbers in the same place (except for q from qzcomplex having form of transposed q from Matlab qz()), the most of matrices from qzcomplex (i.e. b, q and z, except for a?) have the most of their numbers with opposite signs, both their real and their imaginary parts being affected and, as well the real-only numbers too (except where the number is 1). However, the final results of the saddlepath condition Nmat are nevertheless the same.
Best regards George On 19/10/2010 09:21, Sébastien Villemot wrote:
Hi George,
George Perendiageorge@perendia.orangehome.co.uk writes:
we explored alternative paths and it looks like we need to add a complex QZ on lines of the Matlab to Octave.
If I understand correctly, you need a complex QZ decomposition at line 156 of partial_information/PI_gensys.m, where you call the qz() primitive (and only there).
Note for other developers: the qz() primitive under Octave delivers only the *real* generalized Schur decomposition.
C Sims' site provides such wrapper for octave version of gensys.m based on Lapack zgges.f: http://sims.princeton.edu/yftp/gensys/Octave/
but that is using Octave specific mkoctfile compilation and octave specific .c interface.
Considering we are not using mkoctfile, and it may not be acceptable within Dynare, would it be ok if we take up an alternative path to rewrite mjdgges.c as an additional qzzges.c (laving mjdgges as is of course) that returns complex on the same lines as Matalb qz() does, and add it to the e.g. qz subdirectory where mjdgges currenlty resides (though the zdgges.f still needs to be tested if it does the right trick but this would be the way to test it too)?
I think that the easiest way to go is to incorporate Sims' qzcomplex oct-file into Dynare, provided that Sims agrees on putting it under the GPL (which should probably not be a problem).
The fact that this uses mkoctfile is not a problem: it is possible to emulate this command with the build system as we did for the mex command.
The fact that it uses Octave specific Oct-interface is not a problem: we can build this DLL only for Octave (and therefore with a ".oct" extension), since it is useless under MATLAB.
And of course we would put it under mex/octave.
I agree with you that this will force users to have compiled DLLs in order to use your code, but there are already many other features of Dynare in that case (k-order, bytecode...).
If you agree with that line of work, I will contact Sims to ask for permission of including his code under the GPL into Dynare, and then I will make the necessary changes to the build system.
Best,
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev