- gflags <= 2.1.2 has a bug in its exported gflags-config.cmake:
https://github.com/gflags/gflags/issues/110 whereby it sets
gflags_LIBRARIES to a non-existent 'gflags' target.
- This causes linker errors if gflags is installed in a non-standard
location (as otherwise CMake resolves gflags to -lgflags which
links if gflags is installed somewhere on the current path).
- We now check for this case, and search for the correct gflags imported
target and update gflags_LIBRARIES to reference it if found, otherwise
proceed on to the original manual search to try to find gflags.
Change-Id: Iceccc3ee53c7c2010e41cc45255f966e7b13d526
- The CXX11 option has no effect on Windows, as there, any new C++11
features are enabled by default, as such to avoid confusion we only
present the option for non-Windows.
Change-Id: I38925ae3bb8c16682d404468ba95c611a519b9b9
Now that ceres is part of RawHide, there is no need to carry
this spec file with the ceres distribution.
Change-Id: Icc400b9874ba05ba05b353e2658f1de94c72299e
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
The reason this rather serious looking typo has not
caused any problems uptil now is because NUM_ROW_B is
computed but never actually used.
Thanks to Werner Trobin for pointing this out.
Change-Id: Id2b4d9326ec21baec8a85423e3270aefbafb611e
- Optionally use CMake's export() functionality to export the Ceres
build directory as a package into the local CMake package registry.
- This enables the detection & use of Ceres from CMake *without*
requiring that Ceres be installed.
Change-Id: Ib5a7588446f490e1b405878475b6b1dd13accd1f
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
- Split out gflags namespace detection methods:
check_cxx_source_compiles() & regex, into separate functions.
- Use installed/exported gflags CMake configuration (present for
versions >= 2.1) if available, unless user expresses a preference not
to, or specifies search directories, in which case fall back to manual
search for components.
-- Prefer installed gflags CMake configurations over exported gflags
build directories on all OSs.
- Remove custom version of check_cxx_source_compiles() that attempted
to force the build type of the test project. This only worked for
NMake on Windows, not MSVC as msbuild ignored our attempts to force
the build type. Now we always use the regex method on Windows if
we cannot find an installed gflags CMake configuration which works
even on MSVC by bypassing msbuild.
- Add default search paths for gflags on Windows.
Change-Id: I083b267d97a7a5838a1314f3d41a61ae48d5a2d7
And undo the last two botched CLs.
Thanks to Chris Sweeney and Taylor Braun Jones for saving my bacon.
I will do appropriate penance to repend for my sins.
Change-Id: I14de958e651f85e4c1741fba2cb46ffe7e873346
- Eigen/SparseCore is required by covariance_impl, this was added in
v 3.1.0 of Eigen, and thus without at least this version Ceres will
not compile.
- Note that Ubuntu 12.04 provides only version 3.0.5 in the mainline
repository.
- Update docs to match CMake check for Eigen >= 3.2.2 to avoid warning
about reduced sparse performance.
Change-Id: I291bb185d1c76e1e1422429169a76e3f1b828163
- On at least some compilers, -std=c++11 is required in order to compile
against std::shared_ptr & std::unordered_map, which resulted in our
checks failing to find them and using the TR1 versions instead, which
causes conflicts for users using C++11.
- Now, if the compiler supports it and the user enables the CXX11
option, we explicitly enable C++11 before searching for shared_ptr &
unordered_map, which means we should always find the C++11 versions
if they are available.
- As use of CXX11 results in a version of Ceres that must be used with
-std=c++11 for GCC & Clang, we roll this into the Ceres target when
the version of CMake supports this, otherwise we warn the user they
will have to do this themselves.
- CXX11 is OFF by default, to ensure that the behaviour of Ceres is
unchanged from before.
Change-Id: I157ea7a4fadc6bc02da176b8e771f1f327ccaf78
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
- CMake 3.0+ prefers the use of @rpath, and CMake 3.2+ produces a
developer warning if this policy is not set, thus if present we
explicitly specify the new default behaviour.
- http://www.cmake.org/cmake/help/v3.2/policy/CMP0042.html
- Also remove unnecessary check for presence of cmake_policy(), as it
exists in all versions of CMake >= 2.8 (our minimum required version).
Change-Id: Iacbf8186bee4bf07d8a53068fd528cd6237c5efb
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
The test makes sure the Rosenbrock function is correctly minimized from the
canonical starting point using the default settings.
Change-Id: Iea820f976707bde37162981c5db87fac5167ba9e
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
- Include example use of new find_dependency() macro in CMake 3.x to
find dependencies in <Project>Config.cmake files.
- Also fix typo in NNLS modeling docs.
Change-Id: Ie9862b69c0451ee8775826f2957f5e182d937439
The code seemed to imply that its possible to call the Write
method with a null pointer which is never the case. There would
be no point to calling Write.
Thanks to Michael Vitus for pointing this out.
Change-Id: Ic9a276856d0a7e65d53a1cc8742d4831c1a52615
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
Alex Stewart