- 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
- 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
Alex Stewart