Applied changes correspond to clang-tidy fixes
stemming from the modernize-use-equals-default check.
Change-Id: I254b0908a76d464131564b637cd0e42a6b03fb5a
Manifolds are now part of the public API and co-exist
with LocalParameterizations.
1. Add Manifolds to the Problem API.
a. AddParameterBlock(double*, int, Manifold*)
b. SetParameterization(double*, Manifold*)
b. GetManifold(const double*)
c. HasManifold(const double*)
2. Internally Ceres now only uses Manifolds. When the user uses
a LocalParameterization, it is wrapped in a ManifoldAdapter.
3. To preserve the API semantics while keeping the internals clean
we need a new map in ProblemImpl which stores the association
between parameter blocks and local parameterizations. This
is temporary, it will go away once this transition is complete.
4. There are NO algorithmic changes, as in we are not using
any of the expanded interface of the Manifold objects yet.
That will come later.
5. All tests that use LocalParameterization have been duplicated
to use Manifolds, and when this transition is complete the
LocalParameterization based tests will be deleted.
6. Public documentation for the API has been updated. Deprecation
notices to the documentation as well as C++ annotations will come
later.
7. Similar changes have been made to GradientProblem.
Change-Id: I8e03c8ced6e141876ef3eca5740c113afa788f0c
This will help the transition from LocalParameterization to Manifolds,
since most uses of Problem::GetParameterization is to just check
whether a parameter block has a local parameterization associated
with it or not.
Change-Id: Ib3539f377eaed853d7542c9844ec1487aa0fb4d6
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
- As Problem contains a unique_ptr<ProblemImpl> and as defaulted
methods are declared inline where ProblemImpl's implementation is not
available use of '= default' will generate compile errors on strict
compilers.
- This CL moves the definition of defaulted methods to the
implementation.
Change-Id: I7d79757cf684378fadef8e6f4000c84387018cdb
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
This CL changes the implementation of AddResidualBlock() in
ceres::Problem using variadic templates. Also one new overload for
AddResidualBlock() is added using a double** and the number of
parameter blocks.
Change-Id: I007a82a06897335a117213a0d12fedb4a77076a0
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
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
For historical reasons we had a "using namespace std;" in port.h. This
is generally a bad idea. So removing it and along the way doing a bunch
of cpplint cleanup.
Change-Id: Ia125601a55ae62695e247fb0250df4c6f86c46c6
Problem::GetCostFunctionForResidualBlock
Problem::GetLossFunctionForResidualBlock
are added, so that users do not have to maintain this mapping
outside the Problem.
Change-Id: I38356dfa094b2c7eec90651dafeaf3a33c5f5f56
These two methods allow the user to associate upper and lower bounds
with individual parameters inside parameter blocks.
Change-Id: I68dc37f20b64408da510ba06b89a4f08df54ddad
This adds three new public methods to ceres::Problem:
Problem::GetResidualBlocks()
Problem::GetParameterBlocksForResidualBlock()
Problem::GetResidualBlocksForParameterBlock()
These permit access to the underlying graph structure of the problem.
Change-Id: I55a4c7f0e5f325f140cb4830e7a7070554594650
Add a Covariance object to the API.
Given a Problem object and a set of parameter block pairs the
Covariance object computes a sparse covariance matrix corresponding
to those block pairs and provides random access to them.
Constant parameter blocks and parameter blocks with local parameterizations
are correctly handled.
Sparse and dense implementations are provided. With the dense implementation
rank deficient Jacobians can also be handled.
Parts of the code are threaded using OpenMP if available.
Change-Id: I5b49583b3d79579df3e0f334c22567acb23ed4ad
This adds support for removing parameter and residual blocks.
There are two modes of operation: in the first, removals of
paremeter blocks are expensive, since each remove requires
scanning all residual blocks to find ones that depend on the
removed parameter. In the other, extra memory is sacrificed to
maintain a list of the residuals a parameter block depends on,
removing the need to scan. In both cases, removing residual blocks
is fast.
As a caveat, any removals destroys the ordering of the parameters,
so the residuals or jacobian returned from Solver::Solve() is
meaningless. There is some debate on the best way to handle this;
the details remain for a future change.
This also adds some overhead, even in the case that fast removals
are not requested:
- 1 int32 to each residual, to track its position in the program.
- 1 pointer to each parameter, to store the dependent residuals.
Change-Id: I71dcac8656679329a15ee7fc12c0df07030c12af
Following the last commit, which extends the number of parameters blocks autodiff can accept, the interface of Problem::AddResidualBlock is extended to accept up to 10 parameter blocks.
Change-Id: I162c3d1b1868fdda32c1522d57e9a211a9c02f90
Sameer Agarwal