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
- Microsoft deprecated the POSIX Bessel functions: j[0,1,n]() in favour
of _j[0,1,n](), it appears since at least MSVC 2005:
https://msdn.microsoft.com/en-us/library/ms235384(v=vs.100).aspx.
- As this occurs in jet.h (templated public header), although Ceres
suppresses the warning when it itself is built (to suppress a warning
about the insecurity of using std::copy), it will crop up again in
client code (without this fix) unless it is explicitly suppressed
there also.
- Raised as Issue #190:
https://github.com/ceres-solver/ceres-solver/issues/190.
Change-Id: If7ac5dbb856748f9900be93ec0452a40c0b00524
TrustRegionMinimizer evaluates the size of the step
taken in the ambient space, where as the LineSearchMinimizer
was using the norm in the tangent space. This change fixes
this discrepancy.
Change-Id: I9fef64cbb5622c9769c0413003cfb1dc6e89cfa3
- As noted in Issue #193 (in that case for GCC 6), Ceres' use of -Werror
when compiling on *nix can prevent compilation on new compilers that
add new warnings and there is an inevitable delay between new compiler
versions and Ceres versions.
- Removing the explicit use of -Werror, and relying on indirect
verification by maintainers should fix build issues for Ceres releases
on newer compilers.
Change-Id: I38e9ade28d4a90e53dcd918a7d470f1a1debd7b4
- Users can now specify particular components from Ceres, such as
SuiteSparse support) that must be present in a detected version of
Ceres in order for it to be reported as found by find_package().
- This allows users to specify for example that they require a version
of Ceres with SuiteSparse support at configure time, rather than
finding out only at run time that Ceres was not compiled with the
options they require.
- The list of available components are built directly from the Ceres
compile options.
- The meta-module SparseLinearAlgebraLibrary is present if at least
one sparse linear algebra backend is available.
Change-Id: I65f1ddfd7697e6dd25bb4ac7e54f5097d3ca6266
- Previously we were auto-detecting a "64" suffix for the install path
for the Ceres library on non-Debian/Arch Linux distributions, but
we were installing CeresConfig.cmake to an architecture independent
location.
- We now install CeresConfig.cmake to lib${LIB_SUFFIX}/cmake/Ceres.
- Also make LIB_SUFFIX visible to the user in the CMake GUI s/t they can
easily override the auto-detected value if desired.
- Reported by jpgr87@gmail.com as Issue #194.
Change-Id: If126260d7af685779487c01220ae178ac31f7aea
The README.md was woefully out of date, as it was advertising
Ceres Solver as just a non-linear least squares library.
Change-Id: I9a58fb8b63c08ee3852ffbae955e2ca8c90cd6d9
Damon Kohler