Trying to get rid of multiple inheritance here....

The idea is that a DaiAlg<T> has a (protected) variable of type T (called e.g.
grModel, although a shorter name may be worthwile because it is used very
often). The functionality made available originally in InfAlg and in DaiAlg<T>
is then reduced to the following small set of functions:

        /// Save Factors involving ns
        void saveProbs( const VarSet &ns ) { grModel.saveProbs( ns ); }
        /// Restore Factors involving ns
        void undoProbs( const VarSet &ns ) { grModel.undoProbs( ns ); }
        /// Clamp variable n to value i (i.e. multiply with a Kronecker delta \f$\delta_{x_n, i}\f$)
        void clamp( const Var & n, size_t i ) { grModel.clamp( n, i ); }
        /// Set all factors interacting with n to 1
        void makeCavity( const Var & n ) { grModel.makeCavity(n); }
        /// Get number of variables 
        size_t nrVars() const { return grModel.nrVars(); }
        /// Get const reference to variable i 
        const Var & var(size_t i) const { return grModel.var(i); }

The first three functions are used by the general marginalization functions.
makeCavity is used in LC and in MR. nrVars and var are used in test.  Probably,
they can all be removed, since the caller of these functions usually has access
to a copy of the FactorGraph or RegionGraph. Maybe all of them except belief
and logZ etcetera...

Well, actually, we can also define an interface to grModel, e.g. in InfAlg:
        /// Return const reference to grModel, cast to FactorGraph
        virtual const FactorGraph & grM() const = 0; 

        /// Return reference to grModel, cast to FactorGraph
        virtual FactorGraph & grM() = 0; 
and in DAIAlg<T>:
        /// Return const reference to grModel, cast to FactorGraph
        const FactorGraph & grM() const { return grModel; }

        /// Return const reference to grModel, cast to FactorGraph
        FactorGraph & grM() { return grModel; }
which enables us to remove also the functions saveProbs, undoProbs, clamp

A problem that you'll then encounter is the caching: e.g. undoProbs in BP
not only calls grModel.undoProbs but also should init the relevant messages.
So we have to retain undoProbs as a virtual function. In fact, looking at 
all implementations of undoProbs, they are all identical: they call
grModel->undoProbs and init(ns). Further, have a look at the other virtual
functions in FactorGraph and RegionGraph.

Currently, since RegionGraph derives from FactorGraph, it is easy to introduce
bugs by changing factors through the FactorGraph and forgetting to call
RecomputeORs(). To prevent this type of bugs, we should somehow make sure that
RecomputeORs() is called each time that a factor changes.  The easiest way to
do so would be to make a method FactorGraph::setFactor(size_t I, const Factor
&newFactor) which would be overloaded by RegionGraph to call RecomputeORs()
after a factor has changed.

Idea: clamp() gets an undo function.  Currently, undoProb/saveProb is only used
in daialg.cpp to undo a clamping. If we make another interface instead, things
would be more clear. The idea is to give clamp() an argument:   clamp( bool
backup = false ) which backs up the changed factors in case backup is true. If
restore() is called, all factors are restored. This can use the
saveProb/undoProb mechanism, but keep it unexposed to the outside world.
Also, we should store Factors instead of Probs, this is easier.

Maybe it would be a good idea to overload setFactor also in the DAIAlgs so that
they can call init(ns).

Further, the Properties give some overhead. Although it is more
work, it would be cleaner to let each DAIAlg handle their own
properties and use the _properties variable only for communication.

The general philisophy is the following. We have an ABC GraphicalModel, with
specializations FactorGraph and RegionGraph. We also have an ABC ApproxInf that
specifies the general interface of an approximate inference algorithm.
Finally, we have various implementations of ApproxInf, e.g. implementations
using a FactorGraph (BP, MF, LC) and implementations using a RegionGraph (HAK,
JTree, TreeEP). We could use a template for the GraphicalModel owned (or
pointed to or reffered to) by the ApproxInf. The advantage of this strategy is
that it is more transparent and less like a hack. Furthermore, it is not
obvious that an approximate inference algorithm should inherit from a
factorgraph or regiongraph. In fact, if we replace the inheritance relation
by a pointing-to or referring-to relation, we can even save memory and avoid
unnecessary copying of factor graphs and region graphs.

