Thanks George,
this is very useful. I suggest the following. 1) Use matrix implementation in dynare++/tl/cc, and develop the interface to BLAS/LAPACK if additional such functions are needed 2) Start with the code developed by Ondra Kamenik, but try to redesign the code in a less complicated implementation and get rid of the cweb part. You will just mention the ancestry of this new code. Please, send me the classes and functions that you think would be optimal to implement before actually writing code. We have two preoccupations: * the code must be numerically robust for the type of models that we are handling (we will need tests ex-post) * speed because of the Metropolis algorithm that will call this function millions of times per run. 3) Look at OROCOS implementation when in doubt about algorithm details 4) For the moment, we are only concerned with filtering and log-likelihood computation, we will worry about the smoother (and which smoothers we need) later.
All the best,
Michel
G. Perendia wrote:
Deara Michel
Thanks.
As you already pointed out, the KF software from SVN is highly over-modularised and difficult to grasp and modify. But we may not have to modify much as it has some of the functionalities we expect already built-in such as univariate and multivariate filtering, smoother and diffuse priors. Also, as mentioned earlier, it should integrate well with other Dynare applications around dynarelib (it uses sylvester code too). So far the only two package that uses LAPACK/BLAS (either the optimised one , or, if customised, the bespoke ports to various parallel hardware platforms) are dynarelib/KF and a smaller of the two Bayesian filter libraries ( C++ Bayesian Filtering Classes by Michael Stevens, see enclosed draft analysis).
The most of other internet KF packages either rely on BOOST/uBLAS or their own matrix calculation implementations. And, contrary to my initial assumptions, uBLAS, as the most of the BOOST libraries it is part of, is a self-contained "header" library that implements most of important basic algebra functionality in header (.hpp) files. It therefore does not use (or interface) any external libraries such as LAPACK/BLAS and, all compiling and optimisation is done at application compilation time. This is one of reasons our SVN KF still scores high among the alternatives.
Smoothing, however, is also present in one of the Bayesian filtering packages (Orocos ), and though that one relies on BOOST/uBLAS header libraries, the Orocos BFL is probably best (i.e. functionally richest) alternative.
Altogether it is still difficult to derive single recommendation and I am still working on analysing the available packages - The latest draft analysis is enclosed .
Best regards
George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "G. Perendia" george@perendia.orangehome.co.uk Sent: Sunday, May 10, 2009 1:28 PM Subject: Re: Extracting rules for deterministic exogenous vars
There should be no problem if we want ot use it. This was developed for the Dynare project. What do you think of the code?
best
Michel
G. Perendia wrote:
Dear Michel I wandered also if we are allowed to use it. Best regards
George
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "G. Perendia" george@perendia.orangehome.co.uk Sent: Tuesday, May 05, 2009 1:49 PM Subject: Re: Extracting rules for deterministic exogenous vars
Hi George,
my memory that it was too modular in conception and hard to understand, but I will fish it back and send it to you.
All the best,
Michel
G. Perendia wrote:
Dear Michel
I started looking into Kalman Filter DLL - Can we still re-use the (existing?) Kalman Filter code that was/is (??) in SVN for the new
KF?
PS: I.e., I can not see, find or access the Kalman_Filter SVN repo any more - i.e. since the move- - but browsing inside the current repo did
not
find Kalman-Filter."
Best regards
George Mob. +44(0)7951415480 artilogica@btconnect.com
----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "G. Perendia" george@perendia.orangehome.co.uk; "List for Dynare developers" dev@dynare.org Sent: Monday, April 27, 2009 8:33 PM Subject: Re: Extracting rules for deterministic exogenous vars
Hi George,
I have completely forgotten about dr.fuu, I don't see at the moment
what
it is useful for. Porting the varexo_det stuff to C++ isn't a priority, far from it. I would rather that you clean-up existing k_order_perturbation code. When that is done, I would like you to turn to the Kalman filter, but
we
will need to do a careful analysis before starting to code. One question will be which matrix implementation to use in the Kalman filter code? Shall we keep using Ondra's TwoD matrices? Shall we
build
our own (doubtful)? Should we use something like Boost?
Best
Michel
G. Perendia wrote:
> Dear Michel > > I was thinking of re-using some of the existing 2nd order dr1.m code > >
to
> determine dr.fuu and the rules for, if any, deterministic exogenous > >
vars
> (dr.gh??d). > > Looking at the code in dr1.m, for both dr.fuu and deterministic > > >
exogenous
> vars, we need hessian and, for the former, jacobian. Shall I >
retrieve
>
them
> from k-order-perturbation or is there a more elegant way to get >
those
>
rules
> that you can think of? Perhaps we can determine fuu from ghs2 (if >
not
> more elegantly but I can not see it as yet. > > I however could not find where dr.fuu is used other than internally > > >
within
> dr1.m (and dr11_sparse.m). That could mean that we only need hessian > >
and
> only infrequently when if we have deterministic exogenous vars. > > Best regards > > George > Mob. +44(0)7951415480 > artilogica@btconnect.com > > > > > >