- This protects against a client project which invokes
find_package(Ceres) after having called find_package(Foo) with their
own version of FindFoo.cmake which conflicts with Ceres’ exported
version and defines FOO_FOUND, but not the other variables Ceres’
FindFoo.cmake is expecting which can break the detection logic.
Change-Id: I9fe7bfa8a34bb58b09ffe34446da973912cf5587
1. Section title changes.
2. Moving the glog discussion into installation.rst
3. Re-working the faqs into two separate chapters.
Change-Id: I95dd25bace50f0f9077ef114504999190686963e
- If gflags was built & exported with CMake but glog was not, but both
were found then as we now make gflags a public dependency of Ceres if
both it and glog are found, the *name* of the exported gflags CMake
target (gflags-shared or similar) will appear in CERES_LIBRARIES.
- However, as imported targets are not re-exported, this results in a
linker error when compiling client code, as the name of the exported
gflags target is not known to CMake, it assumes it is a library name,
which it is not.
- Confusingly, if glog was built with CMake, this problem would not
occur, as in that case glog’s CMake target would bring in gflags’.
- Now we explicitly call find_package(Gflags) in CeresConfig.cmake if
Ceres was built with gflags as a public dependency (via glog).
Change-Id: I5cc9483a1fae50f4e9e3a8fbba491b645fd45db6
- Previously we were not listing gflags as a public dependency of Ceres
if it and glog were found (and MINIGLOG was not being used). This
does not reflect that if glog was compiled with gflags then it will
#include gflags/gflags.h in glog/logging.h, thus making gflags a
public dependency of anything linking against glog.
- On *nix OSs if glog/gflags are shared libraries this did not result
in a link error when compiling Ceres as the gflags symbols were
indirectly resolved. However, on MSVC this is not the case, and this
could result in unresolved gflags symbol link errors when compiling
Ceres.
- Now we add gflags to the list of public Ceres dependencies if both
glog and gflags are found (and MINIGLOG is not enabled).
Change-Id: I5ce6038fa816781cc81b378522068dc563d29c51
- The latest version of glog supports building with CMake, in which case
it exports itself via CMake as a target that contains important meta
information such as Windows-specific compilation definitions.
- This patch updates FindGlog.cmake such that it can optionally use
an exported glog target if one exists, if not it will fall back to
the current approach whereby the glog components are found manually.
This behaviour (and the implementation) is very similar to that of
FindGflags.cmake.
Change-Id: Idfb5f49c1b457707029bff52068f58237c0e285d
- GLOG_NO_ABBREVIATED_SEVERITIES is the default on Windows, in which
case google::WARNING is not defined.
- Remove Ceres-specific redefinition of WARNING in mock-log.h fork
in place of using non-abbreviated severity in the one place in
levenberg_marquardt_strategy_test where ScopedMockLog is actually
used.
- Remove unnecessary dependency of gradient_checking_cost_function_test
on ScopedMockLog.
Change-Id: I9fb540f638037b6015fd264cfc618c9d60f5686c
- MSVC does not expose standard math constants, such as M_PI in <cmath>
or <math.h> unless _USE_MATH_DEFINES is defined prior to their
inclusion: https://msdn.microsoft.com/en-us/library/4hwaceh6.aspx.
- Use CMake to ensure that this is #defined when both Ceres and the
examples are compiled, even though it should only be an issue for the
examples where M_PI is used.
Change-Id: I67af75b100b8138a65514273d23bfe445d92652c
- gflags_report_not_found() calls gflags_reset_find_library_prefix()
and we only reset CMAKE_FIND_LIBRARY_PREFIXES when performing a manual
search for gflags, but gflags_report_not_found() is also used
before the manual search when searching for an exported gflags target.
- As such, it was possible that we could have cleared
CMAKE_FIND_LIBRARY_PREFIXES rather than reset it if
gflags_report_not_found() was invoked during the exported target
search.
- This patch prevents this possibility by verifying that the cached
version of CMAKE_FIND_LIBRARY_PREFIXES exists before updating it.
Change-Id: I07528ae5f197a366c7da342196b3e977f9a1fc93
- alignas(0) should be ignored, however it results in a build error on
GCC, so instead default to the alignment of double in Jets if
we cannot align to 16-byte boundaries on the platform, but are
compiling with C++11.
Change-Id: I2e54c69516ea2e1447a8bdc138b2dd70050c6dad
- As per Andrew Hunter’s comments in the commit which added Jet
alignment when using C++11 here:
https://ceres-solver-review.googlesource.com/#/c/7100, there is wide
lattitude in the standard about what the maximum supported alignment
can be.
- Previously, we were forcing the alignment to 1, if the value of
alignof(std::max_align_t), which we use as a proxy for the maximum
supported alignment on the platform, was < 16.
- An alignment of 1 is not valid for Jets, as it would weaken the
natural alignment of the types within a Jet, which would typically be
4 (32-bit systems) or 8 (64-bit systems), thus resulting in a compiler
error.
- This was reported as issue 235 for Clang 3.8 on i386:
https://github.com/ceres-solver/ceres-solver/issues/235.
Change-Id: Ie39e5499c64f9231f29ebf4392992b5c9ce2e385
In the process also move some documentation from the file header to
just above the class declaration.
This change is in response to https://github.com/ceres-solver/ceres-solver/issues/233
Change-Id: I08cff1a94c57b67dd2bd8be4dba8c3fce46b68ab
Support for parameter tolerance was added to the line search
minimizer was added a while ago, and calling Solve on a
non-linear least squares problem supported it but for some reason
the GradientProblemSolver::Options struct was missing this
option even though the documentation suggested that it was present!
Thanks to Noah Snavely for reporting this bug.
Change-Id: I57cf4ab396bc822c19fa298529e113b89664a349
This commit relaxes the tolerance value for comparing between the actual
local matrix and the expected local matrix. Without this fix,
EigenQuaternionParameterization.ZeroTest could fail as the difference
exactly matches the value of std::numeric_limits<double>::epsilon().
Change-Id: Ic4d3f26c0acdf5f16fead80dfdc53df9e7dabbf9
Previously, the test for the projective camera model would fail as no
tolerance is set in line 144. To resolve this, this commit changes
assert_equal to assert_near.
Change-Id: I6cd3379083b1a10c7cd0a9cc83fd6962bb993cc9
Any result of an arithmetic operation on floating-point matrices
should never be checked for strict equality with some expected
value, due to limited floating point precision on different machines.
This fixes some occurences of exact checks in the gradient checker
unit test that were causing problems on some platforms.
Change-Id: I48e804c9c705dc485ce74ddfe51037d4957c8fcb
Intel C compiler strictly asks for parallel loops with collapse to be
perfectly nested. Otherwise, compiling Ceres with ICC will throw an
error at line 348 of covariance_impl.cc.
Change-Id: I1ecb68e89b7faf79e4153dfe6675c390d1780db4
1. SubsetParameterization can now be constructed such that all
parameters are constant. This is required for it be used as part
of a ProductParameterization to hold a part of parameter block
constant. For example, a parameter block consisting of a rotation
as a quaternion and a translation vector can now have a local
parameterization where the translation part is constant and the
quaternion part has a QuaternionParameterization associated with it.
2. The check for the tangent space of a parameterization being
positive dimensional. We were not doing this check up till now
and the user could accidentally create parameterizations like this
and create a problem for themselves. This will ensure that even
though one can construct a SubsetParameterization where all
parameters are constant, you cannot actually use it as a local
parameterization for an entire parameter block. Which is how
it was before, but the check was inside the SubsetParameterization
constructor.
3. Added more tests and refactored existing tests to be more
granular.
Change-Id: Ic0184a1f30e3bd8a416b02341781a9d98e855ff7
They were present as debugging checks but were causing problems
with the build on 32bit i386 due to numerical cancellation issues,
where x ~ -epsilon.
Removing these checks only changes the behaviour in Debug mode.
We are already handling such small negative numbers in production
if they occur. All that this change does is to remove the crash.
https://github.com/ceres-solver/ceres-solver/issues/212
Thanks to @NeroBurner and @debalance for reporting this.
Change-Id: I66480e86d4fa0a4b621204f2ff44cc3ff8d01c04
The documentation for ExpectArraysClose and its implementation
did not match.
This change makes the polynomial_test not fail on 64bit AMD builds.
Thanks to Phillip Huebner for reporting this.
Change-Id: I503f2d3317a28d5885a34f8bdbccd49d20ae9ba2
Returning by reference leads to lifetime issues with the default
value which may go out of scope by the time it is used.
Thanks to @Ardavel for reporting this, as this causes graph_test
to fail on VS2015x64.
https://github.com/ceres-solver/ceres-solver/issues/216
Change-Id: I596481219cfbf7622d49a6511ea29193b82c8ba3
This is a follow-up on c/7470. GradientCheckingCostFunction calls
callback_->SetGradientErrorDetected() in its Evaluate method,
which will run in multiple threads simultaneously when enabling
this option in the solver. Thus, the string append operation
inside that method has to be protected by a mutex.
Change-Id: I314ef1df2be52595370d9af05851bf6da39bb45e
Solver::Options::numeric_derivative_relative_step_size to
Solver::Options::gradient_check_numeric_derivative_relative_step_size
Change-Id: Ib89ae3f87e588d4aba2a75361770d2cec26f07aa
1. Use AVX if EIGEN_VECTORIZE_AVX is defined.
2. Make the cost of division same as the cost of multiplication.
These are updates to the original numtraits update needed for eigen 3.3
that Shaheen Gandhi sent out.
Change-Id: Ic1e3ed7d05a659c7badc79a894679b2dd61c51b9
Previously, when using a quaternion to parameterize the camera
orientation, the camera parameter block was split into two
parameter blocks. One for the rotation and another for the
translation and intrinsics. This was to enable the use of the
Quaternion parameterization.
Now that we have a ProductParameterization which allows us
to compose multiple parameterizations, this is no longer needed
and we use a size 10 parameter block instead.
This leads to a more than 2x improvements in the linear solver time.
Change-Id: I78b8f06696f81fee54cfe1a4ae193ee8a5f8e920
- Previously we disabled OpenMP if Clang was detected, as it did not
support it. However as of Clang 3.8 (and potentially Xcode 8) OpenMP
is supported.
Change-Id: Ia39dac9fe746f1fc6310e08553f85f3c37349707
Change the Ceres gradient checking API to make is useful for
unit testing, clean up code duplication and fix interaction between
gradient checking and local parameterizations.
There were two gradient checking implementations, one being used
when using the check_gradients flag in the Solver, the other
being a standalone class. The standalone version was restricted
to cost functions with fixed parameter sizes at compile time, which
is being lifted here. This enables it to be used inside the
GradientCheckingCostFunction as well.
In addition, this installs new hooks in the Solver to ensure
that Solve will fail if any incorrect gradients are detected. This
way, you can set the check_gradient flags to true and detect
errors in an automated way, instead of just printing error information
to the log. The error log is now also returned in the Solver summary
instead of being printed directly. The user can then decide what to
do with it. The existing hooks for user callbacks are used for
this purpose to keep the internal API changes minimal and non-invasive.
The last and biggest change is the way the the interaction between
local parameterizations and the gradient checker works. Before,
local parameterizations would be ignored by the checker. However,
if a cost function does not compute its Jacobian along the null
space of the local parameterization, this wil not have any effect
on the solver, but would result in a gradient checker error.
With this change, the Jacobians are multiplied by the Jacobians
of the respective local parameterization and thus being compared
in the tangent space only.
The typical use case for this are quaternion parameters, where
a cost function will typically assume that the quaternion is
always normalized, skipping the correct computation of the Jacobian
along the normal to save computation cost.
Change-Id: I5e1bb97b8a899436cea25101efe5011b0bb13282
Alex Stewart