[Bayes++] Bayes++ in the new year

[Michael S. <Mic...@ep...>]

Dear all,

This is my first posting to the Bayes++ list. Since we are now in 2004 I 
felt it would be interesting to put out some information.

My recent work in Bayes++ has concentrated on adding a mechanism for 
accessing the many numerical by-products the filter compute. The first 
results of this can be found in CVS. The interface is experimental at 
the moment.

In parallel I am cleaning up the source code comments. The aim is to 
make them accessable to Doxygen so the source will be more self documenting.

Boost is currently working towards the 1.31.0 release. I will be putting 
out a new release of Bayes++ once this becomes available. This will 
include the new expertimental "byproduct" interface.

In the meantime I am maintaining both Bayes++ and uBLAS so they support 
as many compilers as I can easily test. As I don't have VC7.1 and help 
with this compiler is greatly appreciated. The SF bugs tracker has some 
more information on a know problem with this compiler.


-- The byproduct interface --

The existing predict and observe model hierarchies provide a way to 
specify input parameters for filters. In turn, the filters maintain 
state, in various forms, which is directly accessible for output.

Filter predict and observe functions generally involve the computation 
of many values which are relate to the model specified and the state. 
These "byproduct" can be a useful output of these functions. For example 
the innovation (s) computed in many Kalman filter observe implmentations.

"byproduct" parameters differ from existing model parameters in the follow:
  There is no structure (or hierarchy) that can be imposed. They depend 
on the exact numerical implementation of a filter.
  They provide storage for linear algebra computations to place 
temporary variables.
  They are not polymorphic. The filter functions with byproducts are 
specific to that filter implementation and are therefore not virtual. 
The existing virtual functions are generally implemented using the more 
specific byproduct functions.

Advantages:
  Provide an interface to many useful numeric results.
  Allow efficient managment of Matrix/Vec temporaries

Disadvantages:
  The filter interfaces are cluttered with many alternative 
predict/observe functions.
  The filter implementation is exposed in the interface. A filter's 
byproduct interface may change due to implmentation changes.
  The existing automatic managment of observe temporaries (for constant 
z_size) is removed.

Open issues:
  Should byproduct functions be called predict/obeserve? To avoid 
confusion with the exiting polymorphic interfaces a name change may be 
in order. e.g. predict_bp, or predict_byproduct
  To provide a polymorphic mechanism to manage temporaries!

-- 
Happy New Year
	Michael Stevens