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
Apple annoyingly claims that dsyrk_ is a private API, and rejects
submissions to the Apple Store that include this symbol.
Also change ifdef -> ifndef in blas.cc
Change-Id: I432e9519cfe661fc96a58f36a86389a916b6a8b6
- Ensure that, as in the preprocessor, we force num_threads to be 1
if Ceres was compiled without OpenMP to prevent a CHECK() failure
in internal code.
Change-Id: I49d7bdeff81e5bb24aaaa3945018d9d012cd9df9
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
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
Due to floating point and conditioning issues, a system
matrix which is guaranteed to be PSD in exact arithmetic
can appear indefinite to the ConjugateGradientsSolver.
Previously, x'Ax <= 0, the solver returned with numerical
failure. Which the trust region solver will treat as a failed
solve.
But, more general truncated Newton when they encounter indefiniteness
use the step computed till that point instead of declaring failure.
This changes does this and adds a bit more logging.
Change-Id: I0e0cc56ef7d856f1c54ac6d638327b8353039f70
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
The previous commit broke levenberg_marquardt_strategy_test due
a change in the logging string being used.
Change-Id: I6ea69c0bba195c3e7d457d509b9a6605458d69b4
When a user requests an operation on a parameter block which has
not been added to the problem, we now display a more helpful
error message with more context.
Change-Id: Ia7e54815111eb6375b31ed0d1cddca5917138ae1
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
The line search used by the trust region minimizer when enforcing
the bounds constraints starts by using the trust region step
as the line search direction and if that fails, uses the gradient
as the fallback.
The problem with this logic is that the calling code only sees
whether one of the line searches succeeds or not. It does not see
that the fallback happened. So if the fallback line search suceeeds
it still thinks that the line search direction was the trust region
step. This is clearly wrong.
This change, removes the broken fallback logic. This has no effect
on current solution quality as it stands.
Change-Id: Ibc8edd98f77c782ec4708d1e66eaa76d6867b990
- At version 2.1, gflags changed from using the google namespace, to
using gflags by default. However, it can be configured at build time
to be something else (which would be google for legacy compatibility
unless you were evil).
- Ceres previously assumed that gflags was in the google namespace.
- Now, FindGFlags.cmake extracts the namespace when gflags.h is found
and saves it in GFLAGS_NAMESPACE.
- When building the tests and examples that require gflags,
CERES_GFLAGS_NAMESPACE is defined to be the detected namespace, and
all tests/examples now use CERES_GFLAGS_NAMESPACE:: instead of
google:: when calling gflags functions.
Change-Id: Ia333df7a7e2f08ba9f26bbd339c3a785b88f04c4
- 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
Logging was happening unconditionally and that is rather jarring
in certain circumstances, e.g., when ceres is being called
inside a RANSAC loop.
Thanks to Bryan Klingner for reporting this.
Change-Id: I97a0b6c48df51f5f7362eb9d46654712ef044a00
Since the trust region minimizer can use the line search
minimizer when it is solving a box constrained problem,
ensure that the line search options are valid.
Also some minor spacing fixes in the line search code.
Change-Id: Ife04204855cfac389cf980f0a79155d4accc8662
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
The trust region minimizer was detecting convergence due to
the gradient tolerance being reached but was not updating the
step. In the unconstrained test this is usually not a problem,
since we approach this point quite slowly. In the constrained
case however, we may approach this point quite quickly as a
result of the line search.
As a consequence, even though the solver finds the optimal
solution on the boundary, it fails to return this solution
to the user.
Thanks to Rodney Hoskinson for reporting this.
Change-Id: I7b1bcd1310ef0582e05957f43d1700eaabd73241
- As reported by Chris Sweeney on the mailing list, Eigen 3.2.2
trips various warnings in Eigen/SparseQR when compiling with GCC.
- Following Petter Strandmark's suggestion, Eigen headers are now
treated as system headers, which implicitly suppresses all warnings.
Change-Id: I104e8cb3f00935cefb894089bea827771e0e9fd0
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
Inner iterations by default would use problems where the evaluator
was configured to use exactly one thread for doing the evaluation.
This is fine when there are multiple inner iteration problems
being executed concurrently, but every now and then there are
problem decompositions where there is just one parameter block
in the current independent set and it touches every single
residual block. In such cases it is essential that the evaluator
be configured to use multiple threads.
We now pay attention to the size of the independent set and
dynamically configure the number of threads being used by the
outer loop and the evaluator loop.
Thanks to William Rucklidge for reporting this issue and providing
a test problem to debug.
Change-Id: Iaff9a4ab6d2658cf7b61ea213575d23aab604e3b
Trade a small amount of memory to improve the cache coherency of
the SymmetricRightMultiply operation.
The resulting code leads to a 10-20% speedup in the linear solver
end to end.
Change-Id: I8ab2fe152099e849b211b5b19e4ef9f03d8e7f1c
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
1. Extend the implementation of BlockRandomAccessDiagonalMatrix
by adding Invert and RightMultiply methods.
2. Simplify the implementation of the Schur Jacobi preconditioner
using these new methods.
3. Replace the custom storage used inside Block Jacobi preconditioner
with BlockRandomAccessDiagonalMatrix and simplify its implementation
too.
Change-Id: I9d4888b35f0f228c08244abbdda5298b3ce9c466
- CreateBlockJacobian() is only ever used when Eigen >= 3.2.2 is
detected, but was previously defined whenever CERES_USE_EIGEN_SPARSE
was defined with no check on the Eigen version.
- This resulted in an unused-function compile warning that became an
error due to -Werror, preventing compilation when using Eigen < 3.2.2.
Change-Id: I24628ff329f14b087ece66bf2626bdc0de4ba224
The line search minimizer in Ceres does not require that the
problems that is solving is a sum of squares. Over the past
year there have been multiple requests to expose this algorithm
on its own so that it can be used to solve unconstrained
non-linear minimization problems on its own.
With this change, a new optimization problem called
GradientProblem is introduced which is basically a thin
wrapper around a user defined functor that evaluates cost
and gradients (FirstOrderFunction) and an optional LocalParameterization.
Corresponding to it, a GradientProblemSolver and its associated
options and summary structs are introduced too.
An example that uses the new API to find the minimum of Rosenbrock's
function is also added.
Change-Id: I42bf687540da25de991e9bdb00e321239244e8b4
Problem::GetCostFunctionForResidualBlock
Problem::GetLossFunctionForResidualBlock
are added, so that users do not have to maintain this mapping
outside the Problem.
Change-Id: I38356dfa094b2c7eec90651dafeaf3a33c5f5f56
The row/column blocks can be huge when using dynamic sparsity. This
can result in very large memory usage when augmenting the jacobian
with the LM diagonal.
Thanks to Mingsong Dou for reporting this.
Change-Id: I6aa140ceefa98389ae17958f89ca76e0c76f95b8
Keir Mierle