Accumulate the number of steps of the line search algorithm
and report it as part of Summary::FullReport.
Change-Id: I1de12784009a3e08f2a2c2aff5085d57a3c73828
1. Add answers to a number of FAQs.
2. Add a note to the documentation for NumericDiffCostFunction that
NumericDiffOptions needs to be documented and mentioned.
3. Update the docs for Solver::Options::numeric_derivative_relative_step_size
to indicate that this setting only applies to the gradient checker.
4. Remove deprecated constructors from NumericDiffCostFunction and
DynamicNumericDiffCostFunction.
Change-Id: If8fc011b2a5996dbc2c51268aa477550ed014a1c
This method numerically computes function derivatives in different
scales, extrapolating between intermediate results to conserve function
evaluations. Adaptive differentiation is essential to produce accurate
results for functions with noisy derivatives.
Full changelist:
-Created a new type of NumericDiffMethod (RIDDERS).
-Implemented EvaluateRiddersJacobianColumn in NumericDiff.
-Created unit tests with f(x) = x^2 + [random noise] and
f(x) = exp(x).
Change-Id: I2d6e924d7ff686650272f29a8c981351e6f72091
1. Push the boundary handling logic into the underlying array
object. This has two very significant impacts:
a. The interpolation code becomes extremely simple to write
and to test.
b. The user has more flexibility in implementing how out of bounds
values are handled. We provide one default implementation.
Change-Id: Ic2f6cf9257ce7110c62e492688e5a6c8be1e7df2
Often a parameter block is the Cartesian product of a number of
manifolds. For example, a rigid transformation SE(3) = SO(3) x R^3
In such cases, where you have the local parameterization
of the individual manifolds available,
ProductParameterization can be used to construct a local
parameterization of the cartesian product.
Change-Id: I4b5bcbd2407a38739c7725b129789db5c3d65a20
This adds a new wrapper class called DynamicCostFunctionToFunctor
that closes a gap in the current API: the existing
CostFunctionToFunctor can only be used with a SizedCostFunction, where
the number and sizes of all parameter vectors are known at compile-time.
The DynamicCostFunctionToFunctor allows you to wrap a generic
CostFunction into a templated functor which can then be used in a
DynamicAutoDiffCostFunction.
Also updates the existing CostFunctionToFunctor class to internally use
DynamicCostFunctionToFunctor.
Change-Id: I088adc3271c58d2519126c27037c3576965a36d6
Before this change, the default step size
for a function F(x) at x was
step_size = |x| * relative_step_size
if step_size was exactly zero, then to prevent
division by zero we would fall back to relative_step_size.
This however is not good enough, as values of x say 1e-64
would lead to step sizes ~ 1e-70 and dividing by such numbers
leads to inaccurate results. For even smaller numbers, like
1e-300, which I have observed can occur as the optimization
algorithm makes progress, this leads to NaNs.
The key change in this CL is to change the fallback mechanism
to be
step_size = max(|x| * relative_step_size, min_step_size)
where
min_step_size = sqrt(DBL_EPSILON)
This is the recommended minimum value for the step size
for double precision arithmetic on the interwebs.
This results in a small loss of precision in the transcendental
functions test, but that is unavoidable as we are not taking
sufficiently small steps anymore.
On the whole though this will improve the numerical performance
of the algorithm.
To validate this approach, one of the parameter values for the
EasyFunctorTest has been set to 1e-64, which causes the test
to start failing without the corrected fallback logic.
This change should also address some if not all of
https://github.com/ceres-solver/ceres-solver/issues/121
Change-Id: I4a9013ef358626c1ba7b8abad60b3904163d63f6
I think this is all of the cases. These cases arise because pow(a,b) is limited
to real valued results, if the argument and result were complex valued then
these cases would disappear.
NOTE: Since there is so much special casing here, it is worth checking to see
if cpow() is implemented in terms of pow(), and what might be the consequences
of using cpow() on the type std::complex<Jet<double, N> >. It is *possible*
that a separate implementation of cpow might be required also.
Also some comment fixes.
Change-Id: Ia1e38df4cdcb548f778304c2854cacba6e1556ff
1. Add documentation for cubic_interpolation.h
2. Remove the list of publications. It is an incomplete list which is
a pain to maintain.
3. Add a note about the interaction between manifolds and
NumericDiffCostFunction.
4. Fix some of the comments in cubic_interpolation.h to better reflect reality.
5. Updated the version history.
Change-Id: I0b4a5a6f3361d3fc85f1b4aec685cd80540934f1
Since Ceres is moving to using GitHub for issues, and the Google
Code URL in the current copyright header will soon become invalid,
update all the headers.
Change-Id: I1fce70375d1bcf098591f07b4d8f01a5c1e0789c
This CL is required to build Tango.
Inspired by this commit in RedwoodInternal repository:
commit 09dde53c248e04f432b5eccceea5daeedb706aea
Author: Mike Vitus <mike@hidof.com>
Date: Wed Apr 23 11:05:17 2014 -0700
Change-Id: I328b6634969de4ccdd71947945aa67a49ee9073f
MSVC 2013 compiler crashed when not specifying the
template parameter of CubicHermiteSpline explicitly.
Change-Id: I6ab79aea47f55373df5cb7b89e38f8b326ff21c9
This has a measurable impact on interpolation performance.
Also remove an accidentally named enum with an anonymous enum.
Change-Id: Ied6a4b2b06bb27a7f004bd0e01353742e1f84034
The key change is that there is a new layer of abstract,
a Array object that the interpolator depends on.
The Array provides a one dimension or two dimensional
array like interface independent of the underlying representation
of the data.
Also included here is support for vector valued functions.
Change-Id: Ica68f03778cf0d84192db00cd55653f8b4124d51
Delete code needed by old versions of the NDK. We do not build
with these versions of the NDK and do not use STLPort anymore.
Change-Id: I61092db0aa3980cfae6ff57f3f318482027e627f
Example code demonstrates how a sampled function can be
minimized. Also, in the process uncovered some deficiencies
in the CubicInterpolator and BicubicInterpolator interfaces and
fixed them.
Change-Id: I18c8f670fbee076bf1e94d1f45c7477fd71640e8
This bi-cubic interpolation implementation is based
on the cubic convolution algorithm of keys, which allows
us to implement a bi-cubic spline like interpolation scheme
using five one dimensional cubic spline operations.
Change-Id: I116aa8036191c3e654af788323fc8298ae8252a6
Add a cubic interpolator based on the Catmull-Rom spline,
with support for automatic differentiation.
Change-Id: I02ae4c4ea37805ff1f717b05ea805989b474bd59
For historical reasons we had a "using namespace std;" in port.h. This
is generally a bad idea. So removing it and along the way doing a bunch
of cpplint cleanup.
Change-Id: Ia125601a55ae62695e247fb0250df4c6f86c46c6
- Previously we had no defined default value for
sparse_linear_algebra_library_type in Solver::Options if Ceres
was compiled with no sparse library available. Thus in that case,
the default value (dependent upon the compiler) would indicate that
one was available.
- Now we have an explicit option that means no sparse library is
available, which is now the default value in Solver::Options in this
case.
- Add a warning in CMake when the user disables all sparse libraries.
- Fix typos in trust_region_preprocessor_test:
(SUITE/CX)_SPARSE -> (SUITE/CX)SPARSE that induced failures when
no sparse libraries were available.
Change-Id: I869c399a12d42bfc44220cbb25ce6d6dd80236bd
- We now compute & report the cumulative time spent performing the
following tasks as part of a line search:
- Evaluation of the univariate cost function value & gradient.
- Minimization of the interpolating polynomial.
- Total time spent performing line searches.
- This information is now reported for all minimizers, although only in
the case of a constrained problem for the TR minimizer.
- Remove LineSearch::Function abstraction in place of using
LineSearchFunction implementation directly, and remove virtual
functions from LineSearchFunction.
-- LineSearch::Function added an unnecessary level of abstraction since
the user always had to create a LineSearchFunction anyway to use a
Ceres Evaluator, and it added an unncessary virtual function call.
Change-Id: Ia4e1921d78f351ae119875aa97a3ea5e8b5d9877
1. Remove an unused private member in TukeyLoss.
2. The test for RotationMatrixToAngle had an indexing error.
Change-Id: I7decc9448ae0abef53aa435005f739e9e0931e80
Use this function to implement RotationMatrixToAngleAxis.
This simplifies the implementation of RotationMatrixToAngleAxis,
just like Eigen does. It is also autodiff compatible, unlike the
Eigen based version.
Also significantly improve the test coverage of
RotationMatrixToAngleAxis.
Change-Id: Ic192a12fb5de952197ee24b0deedc45f195477f1
Use Eigen's much more complicated conversion routine
when we encounter cases where the angle of rotation is
close to Pi.
Along the way also fix the way angle_axis vectors are
compared by making the matcher more robust.
Thanks to Tobias Strauss for reporting this.
Change-Id: Ia7e65dafad92c48d29d5f3cd22c4d6534789c183
1. Complete restructuring of the documentation to account for
GradientProblemSolver.
2. Update the version history to account for changes since 1.9.0.
3. Add links and document the various examples that ship with ceres.
4. Documentation for GradientProblem GradientProblemSolver.
Change-Id: If3a18f2850cbc98be1bc34435e9ea468785b8b27
Up till now ITERATIVE_SCHUR evaluates matrix-vector products
between the Schur complement and a vector implicitly by exploiting
the algebraic expression for the Schur complement.
This cost of this evaluation scales with the number of non-zeros
in the Jacobian.
For small to medium sized problems there is a sweet spot where
computing the Schur complement is cheap enough that it is much
more efficient to explicitly compute it and use it for evaluating
the matrix-vector products.
This changes implements support for an explicit Schur complement
in ITERATIVE_SCHUR in combination with the SCHUR_JACOBI preconditioner.
API wise a new bool Solver::Options::use_explicit_schur_complement
has been added.
The implementation extends the SparseSchurComplementSolver to use
Conjugate Gradients.
Example speedup:
use_explicit_schur_complement = false
Time (in seconds):
Preprocessor 0.585
Residual evaluation 0.319
Jacobian evaluation 1.590
Linear solver 25.685
Minimizer 27.990
Postprocessor 0.010
Total 28.585
use_explicit_schur_complement = true
Time (in seconds):
Preprocessor 0.638
Residual evaluation 0.318
Jacobian evaluation 1.507
Linear solver 5.930
Minimizer 8.144
Postprocessor 0.010
Total 8.791
Which indicates an end-to-end speedup of more than 3x, with the linear
solver being sped up by > 4x.
The idea to explore this optimization was inspired by the recent paper:
Mining structure fragments for smart bundle adjustment
L. Carlone, P. Alcantarilla, H. Chiu, K. Zsolt, F. Dellaert
British Machine Vision Conference, 2014
which uses a more complicated algorithm to compute parts of the
Schur complement to speed up the matrix-vector product.
Change-Id: I95324af0ab351faa1600f5204039a1d2a64ae61d
Sameer Agarwal