- Required now that Threads is a public dependency for Ceres and so
Threads::Threads will appear in the dependency list for the Ceres
target and so must be defined when Ceres itself is imported.
Change-Id: Ia5f8ea16e8f24cf0158f40e1fc8d3962106459a6
- Required to propagate the threading flags to example targets that
depend upon Ceres and do not directly specify threads as a dependency
to support some *nix builds.
Change-Id: I1c229bd0241da55a203c2b1f8fc28ea43c312e69
This header defined integral types in the pre-C++11 days, and can
be replaced with <cstdint> and the types defined therein.
Also remove a shallow (and incorrect) typedef in include/ceres/types.h
https://github.com/ceres-solver/ceres-solver/issues/409
Change-Id: I398c652f74d24bbeea459672508bf28f591b100f
When Solver::Options::check_gradients is true, Ceres internally
creates a new ProblemImpl object which wraps each CostFunction
in the user's problem with a GradientCheckingCostFunction.
Doing this also requires creating new ParameterBlock objects,
and when support for upper and lower bounds was added to Ceres,
CreateGradientCheckingProblemImpl should also have been updated
to create a problem with the same parameter bounds. As a result,
if check_gradients is enabled for a bounded problem, it constructs
an unconstrained problem and solves it.
This CL fixes this, by introducing Problem::GetParameterLowerBound,
and Problem::GetParameterUpperBound and using them to create a bounded
problem when checking gradients.
Thanks to @pbeeson for not only reporting this problem, but also
providing a small standalone reproduction which made debugging this
possible.
https://github.com/ceres-solver/ceres-solver/issues/379
Change-Id: Id18eb858a7009bf4fa452a21b925922d13f3249f
When using the SchurEliminator to compute a preconditioner, there
is no rhs. This CL removes that limitation and simplifies the
call sites in the two preconditioners.
https://github.com/ceres-solver/ceres-solver/issues/271
Change-Id: I05b8518fdc9f0d1a6d88ae76d3a7e8e838e7204a
All three errors are of the form where, the vector storing
the columns array for a CompressedRowSparseMatrix is being
accessed out of bounds. But in each case, the access is innocuous
because there are other tests which prevent it from being used.
However, if one compiles with debug mode on, the bounds checking
in the underlying std::vector triggers an error.
More details:
1. FromTripletSparseMatrix tried accessing the col vector of
a matrix with zero rows, but the following code was a no-op
because there was nothing to copy.
Adding an early return which deals with this case fixes this.
2. RightMultiply and SquaredColumnNorm had the following loop
while (r > cols_[idx] && idx < idx_end) {
++idx;
}
where cols_ was being accessed out of bounds, before idx < idx_end
was being checked. Swapping the order of the comparisons fixes this
error.
@richmattes reported this error.
https://github.com/ceres-solver/ceres-solver/issues/383
Change-Id: I2dbc90ef24ecaffc6f46f1622339d6053b43db45
This was currently being done in README.md, but thats likely not
the best way to do this, CONTRIBUTING.md is shown to users
if they try to create PR on github.
So this CL pulls out the bits that point folks to Gerrit and puts
them in CONTRIBUTING.md
Change-Id: I1d2be0d89cbff72c0655ba341756dd0f54e2ea7f
CMake support in Android is now standard and the CMake file
has fuller richer functionality than the Android.mk file ever did.
https://github.com/ceres-solver/ceres-solver/issues/364
Change-Id: Ib79bcc19dd47495a81a5d07fafdf06eb8005984e
- In light of the C++11 threads threading option this is no longer
necessary for cross-platform threading support and did not offer a
noticeable performance gain over either the C++11 threads
implementation or OpenMP.
Change-Id: Icb588d520888c19a1775171795b55bcaffb3d256
- Now that we require CMake >= 3.x, we can roll the definition of the
include directories for clients linking against Ceres into the
exported Ceres CMake target via target_include_directories().
- This removes the requirement for CERES_INCLUDE_DIRS.
Change-Id: Ibe3bbf796339871d66138fc9520053d1766f09a8
- Previously we had separate variables for each of the threading
backends, each of which were made mutually exclusive via
cmake_dependent_option(). This has unfortunate side-effects when
trying to disable options if they are not currently enabled, in which
case they are not defined.
- As all the threading options are mutually exclusive, this replaces
all threading option variables with a single variable: CERES_THREADS,
which is constrained to take the value of only the available threading
backends.
Change-Id: I0822eefbac9a30772907b7732add365b37cc8ca0
- As raised in issue #377, GCC_VERSION is not always defined, in which
case we were not enabling compiler optimisations.
- CMAKE_CXX_COMPILER_VERSION is the more modern, uniform method to
verify the compiler version.
- Also removes legacy Apple-GCC (i.e. Apple's fork of GCC prior to their
switch to Clang) logic, and Xcode 4.x logic (in June 2018, Xcode 9.x
is the current version).
- Also removes addition of -march=native on Linux (was not added for
OS X). If users wish to append -march=native (which will affect the
portability of the resulting output) they can do so manually as now
explained in the docs.
- Fixes check for Clang on OS X. As per CMP0025 (CMake 3.0+)
CMAKE_CXX_COMPILER_ID reports AppleClang on OS X, not Clang. Thus
using: if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang") would fail for
AppleClang. Instead, MATCHES should be used instead of STREQUAL to
support both Clang & AppleClang.
Change-Id: I9647030b76f4b85a9ef2deea82d80ed79812ae33
- Add missing CMAKE_FIND_ROOT_PATH_MODE_PACKAGE = ONLY, mimicking what
we previously set for INCLUDE/LIBRARY/PROGRAM s/t the standard
package locations on the host system will not be searched by
find_package() when cross-compiling for iOS.
- Remove now unnecessary forced disabling of dependency options on iOS
as they should now never be found (unless they were explicitly built
for iOS) irrespective of whether the option defaults to ON initially.
Change-Id: I1d2c5da4838d7becb8ebd43f90a88cfc6ded4a1f
- This was a hangover from the pre-Ceres 2.0 era when we needed to
ensure that -std=c++11 was passed to check_cxx_source_compiles() in
FindUnorderedMap/FindSharedPtr if the user had enabled CXX11.
- Unfortunately, the same variable (CMAKE_REQUIRED_FLAGS) is used for
both check_cxx_source_compiles() and check_c_source_compiles(), and
thus updating it to include -std=c++11 would thus break any checks
for C, which are made internally in the version of FindThreads.cmake
shipped with CMake which could cause build breakage as identified
in issue #355.
Change-Id: I36be1a21db14e3839eaf955a80bd952ef40fa269
- This should no longer be required on newer (3.5+) CMake versions and
breaks the detection of supplementary compiler feature information
such as the population of CMAKE_CXX_COMPILE_FEATURES which is required
in order to compile Ceres.
Change-Id: Ibceab545925aa1e829320efa03fb74ef149cbb8b
SuiteSparseQR sets permutation to NULL when the permutation is the
identity. Thus, instead of checking that permutation is not NULL, we
handle that case when building the inverse_permutation.
Change-Id: Ib0fcdf3462da765ac0d4b7aee47a1dff7b3a6c53
std::random_shuffle() is deprecated since C++14 and was removed in
C++17. At least MSVC with C++17 fails to compile this code, I assume
other compilers fail as well.
In a Github discussion (#373) Sameer Agarwal states this line can
likely be dropped and asks for a PR/CL.
https://github.com/ceres-solver/ceres-solver/issues/373
Change-Id: I78e04f36cba398769b8f90916edbdaf33884e7e1
CLUSTER_JACOBI and CLUSTER_TRIDIAGONAL preconditioners require a sparse
Cholesky factorization library. Previously this code was hard coded to
use SuiteSparse. Once SparseCholesky abstraction was introduced, it
became possible to use it with Eigen or CXSParse.
Unfortunately the old code path that was enforcing the requirement
of SuiteSparse was not removed.
This change does the following:
1. Remove the SUITE_SPARSE restriction on CLUSTER_TRIDIAGONAL and
CLUSTER_JACOBI
2. Redo the checking code to be ifdef free and more general.
3. Add bundle adjustment tests to test these configurations.
Thanks to Bjorn Piltz for catching and reporting this bug.
Change-Id: I637791f6f8149694b6aa75f6a4b6417398cb9590
- When Ceres was configured without any multithreading enabled (actually
the default) it would fail to build due to undefined symbols for
ParallelFor() as there was no implementation for that case.
- This adds a trivial single-threaded implementation for that case,
taken from the C++11 threads implementation.
Change-Id: Ib3cfd620842b09f1acafe95b8b0ba3aee4587581
1. Use using directive to pull functions from the std:: namespace
instead of defining a forwarding function.
2. Remove Eigen 2.0 related definitions.
Change-Id: If5f24ef740c17bc4db300fa04f4a2e8f809970d2
Also removed Solver::Summary::num_linear_solver_threads_given
and Solver::Summary::num_linear_solver_threads_used.
Change-Id: I559145ae2e7af597ea06ec03d386645a3a892e9f
Due to the large amount of changes made as part of
the C++11 migration, it makes sense to have a
large version bump.
Change-Id: I2d81828e2d8e23f0829070726e7b3ec31d7f1724
This was currently buried in port.h. Since there is exactly one use
of the max_align_t handling, it is better from a readability
and cleanliness perspective to have this in jet.h.
Change-Id: I2f3dde75df7c333bd95393b9e4fc4cd5160d6afb
- As OPENMP, TBB & CXX11_THREADS are mutually exclusive, and their
implementations are wholly contained within enclosing #ifdefs if the
requisite option is not enabled then the source file is 'empty'.
- This triggers 'xxx.cc has no symbol' warnings when compiling
Ceres statically, as such we now only include these files if they are
not going to be empty.
Change-Id: I5390251b44c5770bbdd4ccb1bc916dbe3b1814a9
The way the SystemTest fixture works is that it takes
a "FooProblem" object as a type, which contains a ceres::Problem
and a ceres::Solver::Options object.
The Options object also contains a linear_solver_ordering which
contains double* which refer to memory that is allocated when
a problem object is created.
So it is important that the lifetime of the ceres::Problem object
and the ceres::Solver::Options object be tied together. But we were
violating this by creating a FooProblem object on the stack, grabbing
its Options struct and passing it to the SystemTest fixture, which
would then create another instance of FooProblem, grab its Problem
object and copy the modified options struct into it.
In the case where a user provided ordering was being used,
this ordering would now be referring to memory allocated by the first
FooProblem object, which would cause Ceres's internal ApplyOrdering
function to fail.
The fix is ofcourse to Problem and Options object that are born
together.
Change-Id: I07c377a9d5fcabbb6c7ca8aa3460206ce045ffa9
1. Remove SolverConfig, this was a wrapper
around Solver::Options. As we experiment
with more Solver::Options, it became a hurdle.
2. Updated generate_bundle_adjustment_tests.py to use
Solver::Options directly.
3. Update system_test to use Solver::Options.
NOTE: generate_bundle_adjustment_tests.py changes are a bit
gunky, but I tried to minimize the changes in this CL
as I am going to introduce new test cases and that
is going to significantly change this file.
Change-Id: I34a2f51824b04ef368a5bbe54fbd7b281381909e
1. Replace CERES_DISALLOW_* with explicitly deleted constructors.
2. Replace use of CERES_ARRAY_SIZE and stack allocated arrays
with std::vector.
3. Move CERES_ALIGN_* macros into manual_constructor.h, which is
the one place they are used and will be deprecated along with that
file.
4. Introduce isnan,isnormal,isinf and isfinite for Jets.
5. Replace IsNormal,IsFinite,IsNaN and IsInfinite with corresponding
c++11 function calls.
Change-Id: I04f33a221aae77d247602150988b6d4aa4efeeab
Sameer Agarwal