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
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
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
1. Break up the monolithic loop in TrustRegionMinimizer::Minimize
into a number of more easily described and analyzed subfunctions.
2. Break out the logic for evaluating the quality of a Trust Region
step into its own object - TrustRegionStepEvaluator.
Change-Id: I08580ecac074cfd74c096cb8e4880cbda3d48296
Computing the covariance matrix for a number of parameter blocks
previously required adding all parameter blocks to the computation and
subsequently assembling the matrix by concatenating all the blocks.
This patch adds the computation of the covariance matrix for a vector
of parameter blocks. All covariance block pairs are added automatically
and the resulting covariance matrix is assembled in the order the
parameter blocks appear.
Change-Id: I3b70c63f16862adc23a1d7fb7a21dde4e68abe9a
I169b637a1e2a106956b536c41d6a514a266e7cc0 marked Jets (in C++11) as
aligned to 16 bytes, and enabled Eigen vectorization. However, to
implement this, we added Eigen includes to port.h.
Turns out this broke some other tricks Ceres uses (redefining Eigen
constants for better performance), so we don't want to do that. Move
most of the implementation to jet.h where it is safe.
Change-Id: I47c6fc4180db1ff674bc660723dd5a2b84254e0d
We currently don't align the infinitesimal part of a Jet to a 16-byte
boundary (and thus force Eigen to avoid using SSE ops)--as a member of a
larger struct, we couldn't guarantee Jets would be allocated on
appropriately-aligned boundaries. However, C++11 adds better support
for requesting alignment: we can use it to guarantee the members will be
properly aligned, and tell Eigen to vectorize.
There is a significant gotcha here: the standard gives wide latitude to
implementations as to which alignments they choose to support. If we
ask for 16 and the system only supports 8, we may have misaligned
Jets. So we test (using alignof(std::max_align_t)) that the current
system supports 16-byte aligned values; if not, we fall back to the
current solution.
Two other small notes:
- This is obviously gated on C++11 support, and
thus we put the logic in port.h and export some useful #defines.
- GCC 4.8.x has a
bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019) that has
max_align_t in the wrong namespace. This will not be a problem with a
modern GCC, but add a small workaround since many systems still ship 4.8.
This results (on a x86 workstation) in a 60% speedup in Jacobian
evaluation on bin/simple_bundle_adjuster problem-16-22106-pre.txt.
Change-Id: I169b637a1e2a106956b536c41d6a514a266e7cc0
Accumulate the number of steps of the line search algorithm
and report it as part of Summary::FullReport.
Change-Id: I1de12784009a3e08f2a2c2aff5085d57a3c73828
1. Add answers to a number of FAQs.
2. Add a note to the documentation for NumericDiffCostFunction that
NumericDiffOptions needs to be documented and mentioned.
3. Update the docs for Solver::Options::numeric_derivative_relative_step_size
to indicate that this setting only applies to the gradient checker.
4. Remove deprecated constructors from NumericDiffCostFunction and
DynamicNumericDiffCostFunction.
Change-Id: If8fc011b2a5996dbc2c51268aa477550ed014a1c
This method numerically computes function derivatives in different
scales, extrapolating between intermediate results to conserve function
evaluations. Adaptive differentiation is essential to produce accurate
results for functions with noisy derivatives.
Full changelist:
-Created a new type of NumericDiffMethod (RIDDERS).
-Implemented EvaluateRiddersJacobianColumn in NumericDiff.
-Created unit tests with f(x) = x^2 + [random noise] and
f(x) = exp(x).
Change-Id: I2d6e924d7ff686650272f29a8c981351e6f72091
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
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
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
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
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
1. Add documentation for cubic_interpolation.h
2. Remove the list of publications. It is an incomplete list which is
a pain to maintain.
3. Add a note about the interaction between manifolds and
NumericDiffCostFunction.
4. Fix some of the comments in cubic_interpolation.h to better reflect reality.
5. Updated the version history.
Change-Id: I0b4a5a6f3361d3fc85f1b4aec685cd80540934f1
Since Ceres is moving to using GitHub for issues, and the Google
Code URL in the current copyright header will soon become invalid,
update all the headers.
Change-Id: I1fce70375d1bcf098591f07b4d8f01a5c1e0789c
This CL is required to build Tango.
Inspired by this commit in RedwoodInternal repository:
commit 09dde53c248e04f432b5eccceea5daeedb706aea
Author: Mike Vitus <mike@hidof.com>
Date: Wed Apr 23 11:05:17 2014 -0700
Change-Id: I328b6634969de4ccdd71947945aa67a49ee9073f
MSVC 2013 compiler crashed when not specifying the
template parameter of CubicHermiteSpline explicitly.
Change-Id: I6ab79aea47f55373df5cb7b89e38f8b326ff21c9
This has a measurable impact on interpolation performance.
Also remove an accidentally named enum with an anonymous enum.
Change-Id: Ied6a4b2b06bb27a7f004bd0e01353742e1f84034
Rob Carroll