1. Default linear solver is Eigen::LDLT
2. Options::max_iterations -> Options::max_num_iterations
3. Options::error_threshold -> Options::cost_threshold
4. Options::relative_step_threshold -> Options::parameter_threshold
5. Options::initial_scale_factor -> Options::initial_trust_region_radius
6. The default values of the above parameters have been changed
to match those in ceres::Solver::Options
7. Status::RUNNING has been removed
8. Update now returns a bool instead of a Status enum and
the status handling has been included in the main loop.
9. Summary::gradient_norm has been changed to Summary::gradient_max_norm
to match the convergence test
10. A member variable cost_ has been added which is computed by Update
11. The test for parameter_tolerance based convergence is made
more robust near zero.
12. Use of double has been replaced by Scalar.
13. Minor clang-formatting
Change-Id: I3cb0e2fd0a0204476bb8718761dc740cdf5e42ce
The solver code must rely on the vectors for
sizing, since not all cost functions will have
NumParameters() or NumResiduals().
Change-Id: Id254ce37507443910edb0064de7907d64558851e
1. Default constructor and initialization for Summary.
2. Add Jacobi scaling.
3. Add bounds on the lm diagonal
4. Use the diagonal of J'J as the regularizer instead of identity.
5. Update the computation of rho to match the change in regularization.
As a result of these changes, the performance of TinySolver is
now the same as ceres::Solver, solving 53 out of 54 problems.
Change-Id: Ie08c3389ac2e3964ffa04411734c06b65835358a
1. Instead of Core/LU just include Eigen/Dense
2. Rename SolverParameters to Options and params to options.
3. Rename Results to Summary.
4. Summary::error_magnitude -> Summary::final_cost.
5. Add Summary::initial_cost.
6. Change definitions of Summary::initial_cost and Summary::final_cost
to match those used by Ceres::Solver.
Change-Id: Id64b78398f47810ca25938a15423c514fc8c164d
1. Change the ordering from NUM_PARAMETERS, NUM_RESIDUALS to
NUM_RESIDUALS, NUM_PARAMETERS in docs and in code.
2. TinySolver::solve -> TinySolver::Solve
Change-Id: I4dca87b971fd9168f1200b53c362669cffc82c1b
Tiny solver is targeted towards small dense least square
solves, where the overhead of calling normal Ceres is too
high. For example, when solving for inverse camera
distortion for every pixel location in a many-megapixel
image. Anecdotally, at one point in the past, tiny solver
was ~20x faster than Ceres for the problems it's intended
for. This is due to two key aspects:
1. Memory is allocated up front: repeated solves incur no
allocation overhead beyond a few scalars on the stack.
2. The cost function is fully inlined into the solver
loop, removing even the cost function call overhead.
Tiny solver originated many years ago as part of
libmv/Blender, where it is still used for distortion solving
today, but the time has come for it to migrate into Ceres.
This commit is just the initial import into Ceres. Follow
up patches will add further cleanups, and add CostFunction
and Jet adapters to make it easier to call tiny solver
(though by using adapters, some performance advantages will
be lost).
Change-Id: I8079535cd41382b1e0ac0ca2fca141711c72b7f8
In case one has a small problem to solve, where
completion is reached within a few milliseconds,
then four decimal places are not enough to accurately
represent the timings of all the separate sub-steps.
Thus, we extend the reported timings to include
six decimal places.
Change-Id: Iaf88a94a1b8896ea7370c75b1de2f05d8671206e
This fixes a Windows specific issue where the
problem-summary reports timings as zero, as long as
the time difference in question is smaller than one
second.
Change-Id: Ibd91874294423af6acda2575eae80f01aabed6d3
Delete CostFunctions and LossFunctions when there are no more
ResidualBlocks referring to them. This is done by maintaining
a map with reference counts for CostFunctions and
LossFunctions.
The same maps are also used at the time of the destruction
of the ProblemImpl object itself. Previously vectors of these
objects were constructed, uniqed and the objects destroyed.
The update to the maps increases the cost of calling AddResidualBlock,
this has been mitigated, actually making AddResidualBlock faster, by
reusing a temporary vector rather than allocating one on the stack
every time.
Change-Id: I28b5287511713d28069ae428e2ff69224c0d03b4
There are platforms where OpenMP is not available. This
patch adds support for Intel Threading Building Blocks (TBB)
as an alternative threading backend.
Change-Id: I94497d7cba0c3cfaccfc992169236f17fe948ae9
- RELEASE.TXT was removed in r11 in favour of source.properties, which
encodes the version number purely numerically, e.g: r15c -> 15.2.xxxx.
- Now we check for either RELEASE.TXT or source.properties and in the
case of the latter convert the numeric minor version number into the
standard alphabetic equivalent.
Change-Id: I8596e32f8d425650d9343bfadc3a8b4f62935df0
- Previously the LAPACK option meant would Ceres link against LAPACK,
whether directly or indirectly via SuiteSparse (if SUITESPARSE=ON),
as such if LAPACK=OFF, the use of SuiteSparse was disabled, even if
it was found.
- To support the use-case of using a limited LAPACK implementation that
satisfies SuiteSparse’s requirements, but potentially not Ceres’ we
now adopt the more conventional terminology whereby the LAPACK option
refers only to whether Ceres itself will directly call LAPACK
routines, not whether it or any of its dependencies will.
- This means that the LAPACK and SUITESPARSE options are now
independent.
- Also unnecessary calls to find_package(BLAS), as find_package(LAPACK)
already searches for BLAS, and appends the resulting libraries to
LAPACK_LIBRARIES if they are found.
Change-Id: I9cf5fa5e4cb621812f6f0526db8d16a7a39c9c8f
- Since the update to optionally use target_compile_features(), the
warning about Ceres propagating C++11 compile flag requirements to
clients was suppressed dependent upon the compiler option selected by
CMake to satisfy the C++11 requirements for Ceres (e.g. if using
-std=gnu++11 instead of -std=c++11).
- Now we display the warning for all CMake versions where any C++11
related flags can be exported in the Ceres target (CMake >= 2.8.12)
if Ceres was compiled with the CXX11 option enabled.
Change-Id: I5cb91e773fc7c41996b5eabadcaa295ebd7de4f7
The row, E, F block pattern 2, 4, 6 is a common one for
bundle adjustment with reprojection error (2 residuals),
homogeneous 3d points (4 params in the E-block), and camera
poses (3 rotation + 3 position = 6 params for the
F-block). This provides a major speedup for BA in the
TheiaSfM library and likely in other applications.
Change-Id: If5df8bfadc7f154856b74c3b38479c14856db47d
The JacobiSVD algorithm in Eigen does not accept fixed sized
matrices when performing a thin SVD. The assert enforcing this
is only triggered in non-Release builds.
So this change calls JacobiSVD with dynamically sized matrices
as a template parameter rather than a fixed size matrix.
https://github.com/ceres-solver/ceres-solver/issues/304#issuecomment-317965814
Thanks to @debalance for reporting this and @leokoppel for
providing a reproduction.
Change-Id: Ifc3d9ff20d5597f08c0f8573bf2fd99a3ed3d4d3
Skip the test in dynamic_sparsity_test when there are no sparse
linear algebra libraries available.
Also fix a minor typo in version_history.rst
Change-Id: Ie7cc14e655c58b6bd9625ce9f9025f94d0624d2d
Update the version history in preparation for 1.13.0RC1 and
also reformat older parts of the version history file.
Change-Id: I133e5966629e8277631ec5d407165ad188efa1e1
1. Replace LineSearch::Summary::optimal_step_size with
LineSearch:Summary::optimal_point which is a FunctionSample.
2. Add the actual vector position and vector gradient of the
point in the FunctionSample
3. Use the above two to get rid of an extraneous function evalation
in LineSearchMinimizer.
Runtime performance is almost 2x improved as a result.
Thanks to @svenpilz for reporting this.
https://github.com/ceres-solver/ceres-solver/issues/296
Change-Id: Iebf2db7acecb2c95c9b1683b73cdc5faab78b02e
1. Move FunctionSample to its own .h/.cc files.
2. Migrate LineSearchFunction::Evaluate to use FunctionSample
for input and output.
Change-Id: I8bfb97e1900d95a4686c9621dda5b584458b45c0
The FindSuiteSparse.cmake refactor had a typo where CCOLAMD
and COLAMD were conflated.
Thanks to @jasjuang for reporting this issue and finding the exact
commit where this bug was introduced.
Change-Id: If8ef6624df3b8b2fd7f0861eafc4700173401435
We keep track of evaluator call and time statistics
via a hashmap containing magic strings. These strings
need to be consistent across the GradientProblemSolver
and Solver as the LineSearchMinimizer is used by both
of these solvers. Previously they were inconsistent
in a manner that GradientProblemSolver was not getting
information about the evaluation timing, and in the
process of fixing that I made it so that the TrustRegionMinimizer
when solving bounds constrained probelms will access/update
this information correctly.
So while I look for a more elegant solution, this CL
is meant to fix the inconsistency by making sure that the
same magic strings are used everywhere.
Change-Id: I120ca0bd1c2f77fde2db15edd9e33286a49dbae9
1. Fix a bug which was causing the cost and gradient evaluation
time to not be reported.
2. Add the number of times cost and gradients are evaluated to
the Summary object and to the output of FullReport.
Change-Id: Id0703cd2dafbf437f3e537fbdc30ae81d5f4f540
1. Remove unused variable.
2. Make inner_product_computer compatible with older versions of Eigen,
which don't have a named enum for Eigen::Upper/Lower.
Change-Id: I927af297f93fc74f7f4b29b39e400ef2d75edbd4
Remove outer product computation code from CompressedRowSparseMatrix.
In the process also remove the crsb_cols and crsb_rows vectors from
the matrix, which were added to carry the block sparsity of the matrix
so that the outer product could be computed fast.
InnerProductComputer and its reliance on BlockSparseMatrix has
rendered all of this code moot.
Change-Id: If3ee0dc8ad4ff79594fd1eebc15a647c4495d726
Despite its relative size, this is very significant change
to Ceres.
Why
===
Up till now, when the user chose SPARSE_NORMAL_CHOLESKY,
the Jacobian was evaluated in a CompressedRowSparseMatrix,
which was then use to compute the normal equations which were
passed to a sparse linear algebra library for factorization.
The reason to do this was because in the case of SuiteSparse,
we were able to pass the Jacobian matrix directly without
computing the normal equations and SuiteSparse/CHOLMOD did the
normal equation computation.
This turned out to be slow, so Cheng Wang implemented a high
performance version of the matrix-matrix multiply to compute
the normal equations, and all the sparse linear algebra libraries
now are passed the normal equations.
So that raises the question, as to what the best representation
of the Jacobian which is suitable for the normal equation computation.
Turns out BlockSparseMatrix is ideal. It brings two advantages.
1. Jacobian evaluation into a BlockSparseMatrix is considerably
faster when using a BlockSparseMatrix than
CompressedRowSparseMatrix. This is because we save on a bunch
of memory copies.
2. To make the matrix multiplication fast and use the block structure
Cheng Wang had to essentially make the CompressedRowSparseMatrix
carry a bunch of sidecar information about the block sparsity,
essentially making it behave like a BlockSparseMatrix. The resulting
code had fairly complicated indexing and complicated the semantics
of CompressedRowSparseMatrix. The new InnerProductComputer class
does away with all that and once this CL goes in, I will be able to
remove all that code and simplify the semantics of
CompressedRowSparseMatrix.
Changes
=======
1. Use InnerProductComputer in SparseNormalCholeskySolver.
2. Change the evaluator instantiated for SPARSE_NORMAL_CHOLESKY with
static sparsity inside evaluator.cc
3. The former change necessitates that we change ProblemImpl::Evaluate
to create the evaluate it needs on its own, because it was
depending on passing "SPARSE_NORMAL_CHOLESKY" as linear solver type
to the evaluator factor to get an Evaluator which can use
CompressedRowSparseMatrix objects for storing the Jacobian.
4. Update the tests for SparseNormalCholeskySolver.
5. Separate out the tests for DynamicSparseNormalCholeskySolver into its
own file.
Change-Id: I2ef7ef8fbfbb4967d0c1ec2068c1c778248fdf5b
Add a class that given a block sparse matrix m will compute
the product m'*m efficiently.
This code is refactoring and cleanup of the code in
CompressedRowSparseMatrix devoted to computing the inner product.
In that class, the code is mistakenly said to be computing
the outer product. It is also devoted to computing the inner
product of a CompressedRowSparseMatrix with itself.
This code works with BlockSparseMatrix objects instead, which
are simpler to deal with as they are better structured to handle
block sparse matrices.
Change-Id: I920fee1a396bb0fcae9e6f7e46a308c7391d21aa
There was a bug in the trust region preprocessor where no fill
reducing ordering was computed for the case of SPARSE_SCHUR + CX_SPARSE
but this was not signaled to SchurComplementSolver, so it was using
a naive/natural ordering. To fix this two changes are made:
1. TrustRegionProcessor's logic for signaling the ordering to the
linear solver has been re-worked. The surrounding code has also
been re-organized for better readability.
2. In SchurComplementSolver::SolveReducedSystem the row and column
block structure has been added to the CompressedRowSparseMatrix
containing the Schur complement so that block AMD can be used.
As a result of these changes the linear solve time for
problem-744-543562-pre.txt has been brought down from 58 seconds to
35 seconds.
Change-Id: I4d82efce05175260f97b1f925f8a1b4a9d650cae
Sameer Agarwal