Add a pointer about how the theory and practice of Trigg's correction
for loss function differs when the second derivative of the loss
function becomes positive.
https://github.com/ceres-solver/ceres-solver/issues/573
Change-Id: Ic22ce91cc230f7ed7fa7b70a1cc2050919039828
1. Add a move constructor to NumericDiffCostFunction, DynamicAutoDiffCostfunction
and DynamicNumericDiffCostFunction.
2. Add optional ownership of the underlying functor.
3. Update docs to reflect this as well as the variadic templates that allow an
arbitrary number of parameter blocks.
Change-Id: I57bbb51fb9e75f36ec2a661b603beda270f30a19
Add Ownership semantics to the AutoDiffCostFunction
This allows several benefits, such as pointer ordering always being the
same for numerical repeatability (due to blocks being ordered by
pointer address), memory adjacency for better cache performance, and
reduced allocator pressure / overhead.
This is then made use of in libmv by preallocating the errors and
cost functions into vectors
Change-Id: Ia5b97e7249b55a463264b6e26f7a02291927c9f2
Simplify the semantics for Problem::EvaluateResidualBlock to
not ignore the presence of EvaluationCallback and add another method
EvaluateResidualBlockAssumingParametersUnchanged to handle the case
where the user has an EvaluationCallback but knows that the parameter
blocks do not change between calls.
Updated the documentation for the methods and EvaluationCallback to
reflect these semantics.
Also added tests for Evaluation related methods calling i
EvaluationCallback when its present.
https://github.com/ceres-solver/ceres-solver/issues/483
Change-Id: If0a0c95c2f1f92e9183a90df240104a69a71c46d
1. The MathJax font configuration is moved into conf.py and removed
from make_docs.py along with better font sizing.
2. Remove the bread crumb replacement as it is not working anymore.
3. Fix a parsing error in nnls_modeling.rst which the new version of
sphinx barfed on.
Change-Id: Ia3c2e732323a8b5cabafe851ac5ca0f0c82da071
Local parameterizations with zero tangent/local size will cause the
corresponding parameter block to be treated as constant.
https://github.com/ceres-solver/ceres-solver/issues/347
Change-Id: I554a2acc420f5dd9d0cc7f97b691877eb057b2c0
This CL adds a local parameterization for a n-dimensional
line, which is represented as an origin point and a direction.
The line direction is updated in the same way as a
homogeneous vector and the origin point is updated
perpendicular to the line direction.
Change-Id: I733f395e5cc4250abf9778c26fe0a5ae1de6b624
Some methods in Problem do not modify the parameter block
and those methods now allow the user to call them with const double*.
The methods are
RemoveParameterBlock
SetParameterBlockConstant
IsParameterBlockConstant
GetParameterization
GetParameterLowerBound
GetParameterUpperBound
https://github.com/ceres-solver/ceres-solver/issues/479
Change-Id: I59dcb77134f59576dd498bd732e29aae9abd28b1
This method gives the user the ability to evaluate a given residual
block.
A couple of minor cleanups.
Problem::problem_impl_ -> Problem::impl_
NULL -> nullptr
https://github.com/ceres-solver/ceres-solver/issues/417
Change-Id: I6dd94762c475fa264c387b8c93d516f6e06fe832
When Solver::Options::check_gradients is true, Ceres internally
creates a new ProblemImpl object which wraps each CostFunction
in the user's problem with a GradientCheckingCostFunction.
Doing this also requires creating new ParameterBlock objects,
and when support for upper and lower bounds was added to Ceres,
CreateGradientCheckingProblemImpl should also have been updated
to create a problem with the same parameter bounds. As a result,
if check_gradients is enabled for a bounded problem, it constructs
an unconstrained problem and solves it.
This CL fixes this, by introducing Problem::GetParameterLowerBound,
and Problem::GetParameterUpperBound and using them to create a bounded
problem when checking gradients.
Thanks to @pbeeson for not only reporting this problem, but also
providing a small standalone reproduction which made debugging this
possible.
https://github.com/ceres-solver/ceres-solver/issues/379
Change-Id: Id18eb858a7009bf4fa452a21b925922d13f3249f
This change is provided on behalf of Steve Hsu.
Tested by compiling and inspecting the documentation.
Change-Id: Ib892bcc3ad76cba1bad133a1fd1d26468d0e6437
The non-linear least squares solver had the ability to update the
user's parameters every iteration. Now GradientProblemSolver can
do the same.
Also a few minor Sphinx markup related cleanup to the documentation
which were found in the process of updating Sphinx on my machine
and adding the docs for this feature.
This fixes https://github.com/ceres-solver/ceres-solver/issues/246
Change-Id: Ib6b90ac22be8bfb60b14f25ad52082ba371af164
Binary operations between Jets and doubles are well defined
and should not require an explicit conversion to Jets to work.
This was an oversight earlier and lead to overzealous conversions
all over our in our example code.
Change-Id: I1799770818e136edfc0a5802d86037ce9aec4923
1. Section title changes.
2. Moving the glog discussion into installation.rst
3. Re-working the faqs into two separate chapters.
Change-Id: I95dd25bace50f0f9077ef114504999190686963e
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
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
- 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
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
Sameer Agarwal