VectorMap uses a straightforward stl::map of Vectors. It has O(log n)
insert and access, and is fairly fast at both. However, it has high overhead
for arithmetic operations such as +, scale, axpy etc...
VectorBTree uses a functional BTree as a way to access SubVectors
in an ordinary Vector. Inserting is O(n) and much slower, but accessing,
is O(log n) and might be a bit slower than VectorMap. Arithmetic operations
are blindingly fast, however. The cost is it is not as KISS as VectorMap.
Access to vectors is now exclusively via operator[]
Vector access in VectorMap is via a Vector reference
Vector access in VectorBtree is via the SubVector type (see Vector.h)
Feb 16 2010: FD: I made VectorMap the default, because I decided to try
and speed up conjugate gradients by using Sparse FactorGraphs all the way.
fixed a nasty bug and change the internal data type of subgraph preconditioner from reference to boost shared pointer. reference is not a good idea for class members, because no type checking will happen
This simplifies Bayes nets quite a bit. Also created a Conditional base class, derived classes ConditionalGaussian and SymbolicConditional
Finally, some changes were needed because I moved some headers to .cpp
* Factors are now templated on the configuration type. Factor Graphs are now templated on the factor type and configuration type.
* LinearFactor is a factor on an FGConfig.
* LinearFactorGraph uses LinearFactor and FGConfig.
* NonLinearFactor is still templated on Config.
* NonLinearFactorGraph uses NonLinearFactors, but is still templated on Config.
* Tests and VSLAMFactor have been updated to reflect those changes.
(1) FactorGraph and NonlinearOptimizer now no longer have a .cpp file, but a -inl.h file as in [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ Style Guide]. This means if you expect to instantiate one of the functions in a cpp file, you have to include the -inl.h file.
(1) getOrdering is now in FactorGraph, and the non-linear version does *not* take a config anymore.
Long version: I made this change because colamd works on the graph structure alone, and should not depend on the type of graph. Instead, because getOrdering happened to implemented in LinearFactorGraph first, the non-linear version converted to a linear factor graph (at the cost of an unnecessary linearization), and then threw all that away to call colamd. To implement this in a key-neutral way (a hidden agenda), i had to modify the keys_ type to a list, so a lot of changes resulted from that.
Frank Dellaert
Alex Cunningham
Kai Ni
Richard Roberts