Eigen upstream was broken a little while ago, and it seemed to be
the case that we needed a fix for using the LLT factorization on
ARM.
This has been fixed and AFAIK there are no stable eigen releases
with this bug in it.
For full gore, see
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=992
In light of the fix, the extra layer of indirection introduced earlier
is not needed and we are reverting to normal programming.
Change-Id: I16929d2145253b38339b573b27b6b8fabd523704
It seems that Eigen's LLT factorization is broken on ARM.
This patch enables the use of LDLT factorization instead of LLT
factorization. The switch is controlled at compile time using a
preprocessor define - CERES_USE_EIGEN_LDLT.
By default we continue to use LLT factorization though.
To make the switching easier without introducing the Cholesky factorization
based inversion and linear system solve routines have been abstracted into
two new functions.
Android.mk has been updated to enable the LDLT factorization, but
the cmake file has not been updated as I will leave it to Alex's
capable hands to do proper detection of ARM as a target platform.
Change-Id: Iffe3abd2ce894de2a388b454df3da909b482d5e5
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
Make the definition of CERES_NO_THREADS conditional on the presence
of the CERES_HAVE_PTHREADS define.
This allows the user to enable threading in ceres using a combination
of CERES_EXTRA_DEFINES and linker flags which they need to do in
their app.
Change-Id: I43b99fc829001166e2f6dfb0a770768e61470591
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
Replace SolverImpl with
a. A minimizer specific preprocessor class.
b. A generic Solve function inside solver.cc
c. Presummarize and Postsummarize functions to handle
updates to the summary object.
The existing SolverImpl class was a mixture of the above three
things and was increasingly complicated code to follow. This change,
breaks it into its three separate constituents, with the aims of
better separation of concerns and thus better testability and
reliability.
The call to Solver::Solve() now consists of
1. Presummarize - summarize the given state of the problem and solver
options.
2. Preprocess - Setup everything that is needed to call the minimizer.
This includes, removing redundant parameter and residual blocks,
setting up the reordering for the linear solver, creating the
linear solver, evaluator, inner iteration minimizer etc.
3. Minimize.
4. Post summarize - summarize the result of the preprocessing and the
solve.
Change-Id: I80f35cfc9f2cbf78f1df4aceace27075779d8a3a
The script assert_ndk_version.sh used to require that the user
either define ANDROID_NDK_ROOT or ndk-build be in the path
so that ANDROID_NDK_ROOT can be inferred.
But since we are always calling this script from within an
Android.mk file, ndk-build already defines a variable called
NDK_ROOT, which we can pass to the script, thereby simplifying it
and making it more robust.
Change-Id: I31d66529a36a93e760e0dd0f17cfe61428fbac55
- Ceres now requires Android NDK version >= r9d to compile, Jørgen's
script allows a clean way to verify this condition is met before
trying to compile for Android.
- Note that this is a modified version of the original script, which
adds support for versions >= 10, and fixes extraction of the version
number now that the architecture is also included.
Change-Id: Icd7ffd25407bcf29af007e30b5da5d18eb799adf
- Previously we overwrote the default (empty) config.h in the source
tree with a configured config.h, generated using the current compile
options.
- This was undesirable as it could lead to inadvertant commits of the
generated config.h.
- This patch moves the default config.h to <src>/config/ceres/internal,
separate from the other headers, thus if Ceres is compiled without
CMake this directory will now also have to be included. This
directory is _not_ added to the CMake include directories for Ceres
(thus the default config.h is never used when compiling with CMake).
- When using CMake, the generated config.h is now placed in
<build>/config/ceres/internal, which is in turn added to the include
directories for Ceres when it is compiled, and the resulting config.h
is copied to ceres/internal when installed.
Change-Id: Ib1ba45e66e383ade2ebb08603af9165c1df616f2
- Previously we passed all compile options to Ceres via add_definitions
in CMake. This was fine for private definitions (used only by Ceres)
but required additional work for public definitions to ensure they
were correctly propagated to clients via CMake using
target_compile_definitions() (>= 2.8.11) or add_definitions().
- A drawback to these approaches is that they did not work for chained
dependencies on Ceres, as in if in the users project B <- A <- Ceres,
then although the required Ceres public compile definitions would
be used when compiling A, they would not be propagated to B.
- This patch replaces the addition of compile definitions via
add_definitions() with an autogenerated config.h header which
is installed with Ceres and defines all of the enabled Ceres compile
options.
- This removes the need for the user to propagate any compile
definitions in their projects, and additionally allows post-install
inspect of the options with which Ceres was compiled.
Change-Id: Idbdb6abdad0eb31e7540370e301afe87a07f2260
This compiler defines shared_ptr in std::tr1 namespace, but
for this <tr1/memory> is to be included. Further, this compiler
also does have <memory> header which confused previous shared
pointer check.
Simplified logic around defines now, so currently we've got:
- CERES_TR1_MEMORY_HEADER defined if <tr1/memory> is to be
used for shared_ptr, otherwise <memory> is to be used.
- CERES_TR1_SHARED_PTR defined if shared_ptr is defined in
std::tr1 namespace, otherwise it's defined in std namespace.
All the shared_ptr checks are now moved to own file FindSharedPtr
which simplifies main CMakeLists.
Change-Id: I558a74793baaa0bd088801910a356be4ef17c31b
Solver::Options::linear_solver_ordering and
Solver::Options::inner_iteration_ordering
were bare pointers even though Solver::Options took ownership of these
objects.
This lead to buggy user code and the inability to copy Solver::Options
objects around.
With this change, these naked pointers have been replaced by a
shared_ptr object which will managed the lifetime of these objects. This
also leads to simplification of the lifetime handling of these objects
inside the solver.
The Android.mk and Application.mk files have also been updated
to use a newer NDK revision which ships with LLVM's libc++.
Change-Id: I25161fb3ddf737be0b3e5dfd8e7a0039b22548cd
Now that the trust region minimizer depends on the line search
minimizer, conditional compilation of the line search minimizer
will lead to build breakages, so this option is now not available.
It is not expected to have as significant impact on users as the
amount of code in the line search minimization algorithm is
rather small to begin with.
Change-Id: I2aa6b6e6e3931b6428dbda654f14faf1ac6dd130
Depending on the compiler + standard library combination,
unordered_map/set may or may not be available. If available
they maybe in the std or the std::tr1 namespaces.
Apple switched to using libc++ with 10.9.0 which places
unordered_map in std, breaking our assumptions about the
platform.
This change refactors our logic for dealing with the namespace
switching, making it a three state thing rather than two. There
are three defines now, CERES_NO_UNORDERED_MAP, CERES_STD_UNORDERED_MAP
and CERES_TR1_UNORDERED_MAP. Earlier the first two were conflated
into one, leading to the breakage.
Change-Id: I904fe8c49529169bdefa9f2ee6d629e7eab0b855
This class is used in the SchurJacobiPreconditioner for
storing the preconditioner matrix. Using it speeds up
the computation of the preconditioner by ~15% due to
the elimination of a hash table lookup.
Change-Id: Iba2b34aad0d9eb9bcb7f6e6fad16aa416aac0d2a
1. When a LAPACK implementation is present, then
DENSE_QR, DENSE_NORMAL_CHOLESKY and DENSE_SCHUR
can use it for doing dense linear algebra operations.
2. The user can switch dense linear algebra libraries
by setting Solver::Options::dense_linear_algebra_library_type.
3. Solver::Options::sparse_linear_algebra_library is now
Solver::Options::sparse_linear_algebra_library_type to be consistent
with all the other enums in Solver::Options.
4. Updated documentation as well as Solver::Summary::FullReport
to reflect these changes.
Change-Id: I5ab930bc15e90906b648bc399b551e6bd5d6498f
1. Add -DLINE_SEARCH_MINIMIZER to CMake to make the line search
minimizer optional.
2. Better handling of -DSUITESPARSE/-DCXSPARSE in top level cmake
file.
3. Disable code which will never be used if SuiteSparse and/or
CXSparse is not available.
4. Update build docs.
5. Update jni/Android.mk
6. Minor lint cleanup from William Rucklidge.
Change-Id: If60460a858000df82faed7a6bb056dd2bfdde562
1. Added a Preconditioner interface.
2. SCHUR_JACOBI is now its own class and is independent of
SuiteSparse.
Change-Id: Id912ab19cf3736e61d1b90ddaf5bfba33e877ec4
1. New LineSearchDirection interface, factory and instances.
2. Cleanup of LineSearchMinimizer to use the State and Direction objects.
3. LBFGS -> LowRankInverseHessian.
4. Refactoring of the RunCallbacks function and share it across
LineSearchMinimizer and TrustRegionMinimizer.
Change-Id: I19354afc6f5d6567b28918710c2012dc30ef8f32
1. Add a line search based minimization loop.
2. Currently this loop supports steepest descent and three
kinds of non-linear conjugate gradient algorithms.
3. Update SolverImpl to talk to LineSearchMinimizer.
4. Update IterationCallback to carry information about
line search.
5. Update LineSearch to take the initial point as input,
saving on one function evaluation.
6. Updates to the external API.
Change-Id: I901a0e89fc948451ab34c743e70f3dec57c9405e
An interface for line search and an initial implementation of
Armijo line search with and without interpolation.
Change-Id: I234da141be36172819a6df87ce5625aa8b58ed47
1. polynomial_solver* -> polynomial*.
2. Added support for differentiating polynomials.
2. Added support for interpolating polynomials from function
values and gradients.
3. Added support for minimizing polynomials by solving
for the roots of their derivatives in an interval.
4. Added support for finding the minimum of a polynomial
that interpolates function values and gradients in
an interval.
Change-Id: Id7e6764ad4db09c3edd60f1378c7f50f20dd08dc
The NDK build of Ceres was broken; this fixes it and also
disables a useless warning that shows up in NDK 8b.
Change-Id: I54cfb3de7ccea4a0864385f7ffdb55d8f3431f34
Add automatic recursive independent set decomposition.
Clean up the naming and the API for inner iterations.
Change-Id: I3d7d6babb9756842d7367e14b7279d2df98fb724
On certain NDK build configurations, one of the innermost
parts of the Schur eliminator would get compiled
incorrectly. The compiler changed a -= to a +=.
The normal Ceres unit tests caught the problem; however,
since it is not possible to build the tests with the NDK
(only with the standalone toolchain) this was difficult to
track down. Finding the issue involved pasting the schur
eliminator unit test inside of solver_impl.cc and other such
hacks.
Change-Id: Ie91bb545d74fe39f0c8cbd1a6eb69ee4d8b25fb2
For problems with a small number of variables, but a large
number of residuals, it is sometimes beneficial to use the
Cholesky factorization on the normal equations, instead of
the dense QR factorization of the Jacobian, even though it
is numerically the better thing to do.
Change-Id: I3506b006195754018deec964e6e190b7e8c9ac8f
This adds a Android.mk build that builds a Ceres static library
suitable for embetting in larger Android applications. This is
useful when needing to build Ceres without GPL'd components, since
the standalone toolchain (needed for the CMake Android build) does
not work with STLPort.
Change-Id: I8d857237f6f82658741017d161b2e31d9a20e5a7
Sameer Agarwal