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.
To support faster development *and* better performance Richard and I pushed through a large refactoring of NonlinearFactors.
The following are the biggest changes:
1) NonLinearFactor1 and NonLinearFactor2 are now templated on Config, Key type, and X type, where X is the argument to the measurement function.
2) The measurement itself is no longer kept in the nonlinear factor. Instead, a derived class (see testVSLAMFactor, testNonlinearEquality, testPose3Factor etc...) has to implement a function to compute the errors, "evaluateErrors". Instead of (h(x)-z), it needs to return (z-h(x)), so Ax-b is an approximation of the error. IMPORTANT: evaluateErrors needs - if asked - *combine* the calculation of the function value h(x) and the derivatives dh(x)/dx. This was a major performance issue. To do this, boost::optional<Matrix&> arguments are provided, and tin EvaluateErrors you just says something like
if (H) *H = Matrix_(3,6,....);
3) We are no longer using int or strings for nonlinear factors. Instead, the preferred key type is now Symbol, defined in Key.h. This is both fast and cool: you can construct it from an int, and cast it to a strong. It also does type checking: a Symbol<Pose3,'x'> will not match a Symbol<Pose2,'x'>
4) minor: take a look at LieConfig.h: it help you avoid writing a lot of code bu automatically creating configs for a certain type. See e.g. Pose3Config.h. A "double" LieConfig is on the way - Thanks Richard and Manohar !
Frank Dellaert
Alex Cunningham
Richard Roberts
Chris Beall