VLOG_IF's evaluation order is ambiguous - does it mean
`if (cond) VLOG(lvl)` or `if (VLOG_IS_ON(lvl) && cond) LOG(INFO)`?
In particular, the way it works now is inconsistent with the way the
rest of the LOG macros evaluate their arguments.
Fixing this would be hard, and the macro's behavior would still surprise
some people. Replacing it with an if statement is simple, clear, and unambiguous.
Change-Id: I97a92d17a932c0a5344a1bf98d676308793ba877
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
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
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
Introduce IsSetConstantByUser method which indicates whether
the user set the parameter block constant or not.
Changed the definition of IsConstant() to indicate if the
parameter block is effectively constant or not, which is
now the uniion of two conditions - the user set it to be constant
or the local tangent space is of size zero. Currently
this change has no effect as we do not allow local parameterizations
with zero tangent space size, but thats an inconsistency we are
working on fixing.
A variety of code cleans up to parameter_block.h
1. Remove an old TODO comment which is not really actionable.
2. Remove Init() method.
3. NULL -> nullptr
4. memcpy -> std::copy
Change-Id: I12973ee0f053fa22f09908cf36e9aa57d9d8dd74
This header defined integral types in the pre-C++11 days, and can
be replaced with <cstdint> and the types defined therein.
Also remove a shallow (and incorrect) typedef in include/ceres/types.h
https://github.com/ceres-solver/ceres-solver/issues/409
Change-Id: I398c652f74d24bbeea459672508bf28f591b100f
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
- In light of the C++11 threads threading option this is no longer
necessary for cross-platform threading support and did not offer a
noticeable performance gain over either the C++11 threads
implementation or OpenMP.
Change-Id: Icb588d520888c19a1775171795b55bcaffb3d256
1. Replace HashMap and HashSet with std::unordered_map and
std::unordered_set respectively.
2. Extract the pair hasher into a struct pair_hash.
3. Delete collections_port.h
4. Convert explicit iterator based loops to auto based
loops where sensible.
Change-Id: Ib88bcd13a7463d18435639d3b771abaa52080efb
A Ceres Context holds common global state that can be re-used within
Ceres. The Context current contains a thread pool if compiling with
C++11 threading support. Threads are expensive to create and destroy so
it is good to maintain across multiple Ceres solves.
Tested by compiling with and without TBB support and ran unit tests. Ran
bazel as well.
Change-Id: I82f598dfae642aa0e81a6039dc174608a5e8dbfb
Delete CostFunctions and LossFunctions when there are no more
ResidualBlocks referring to them. This is done by maintaining
a map with reference counts for CostFunctions and
LossFunctions.
The same maps are also used at the time of the destruction
of the ProblemImpl object itself. Previously vectors of these
objects were constructed, uniqed and the objects destroyed.
The update to the maps increases the cost of calling AddResidualBlock,
this has been mitigated, actually making AddResidualBlock faster, by
reusing a temporary vector rather than allocating one on the stack
every time.
Change-Id: I28b5287511713d28069ae428e2ff69224c0d03b4
There are platforms where OpenMP is not available. This
patch adds support for Intel Threading Building Blocks (TBB)
as an alternative threading backend.
Change-Id: I94497d7cba0c3cfaccfc992169236f17fe948ae9
Despite its relative size, this is very significant change
to Ceres.
Why
===
Up till now, when the user chose SPARSE_NORMAL_CHOLESKY,
the Jacobian was evaluated in a CompressedRowSparseMatrix,
which was then use to compute the normal equations which were
passed to a sparse linear algebra library for factorization.
The reason to do this was because in the case of SuiteSparse,
we were able to pass the Jacobian matrix directly without
computing the normal equations and SuiteSparse/CHOLMOD did the
normal equation computation.
This turned out to be slow, so Cheng Wang implemented a high
performance version of the matrix-matrix multiply to compute
the normal equations, and all the sparse linear algebra libraries
now are passed the normal equations.
So that raises the question, as to what the best representation
of the Jacobian which is suitable for the normal equation computation.
Turns out BlockSparseMatrix is ideal. It brings two advantages.
1. Jacobian evaluation into a BlockSparseMatrix is considerably
faster when using a BlockSparseMatrix than
CompressedRowSparseMatrix. This is because we save on a bunch
of memory copies.
2. To make the matrix multiplication fast and use the block structure
Cheng Wang had to essentially make the CompressedRowSparseMatrix
carry a bunch of sidecar information about the block sparsity,
essentially making it behave like a BlockSparseMatrix. The resulting
code had fairly complicated indexing and complicated the semantics
of CompressedRowSparseMatrix. The new InnerProductComputer class
does away with all that and once this CL goes in, I will be able to
remove all that code and simplify the semantics of
CompressedRowSparseMatrix.
Changes
=======
1. Use InnerProductComputer in SparseNormalCholeskySolver.
2. Change the evaluator instantiated for SPARSE_NORMAL_CHOLESKY with
static sparsity inside evaluator.cc
3. The former change necessitates that we change ProblemImpl::Evaluate
to create the evaluate it needs on its own, because it was
depending on passing "SPARSE_NORMAL_CHOLESKY" as linear solver type
to the evaluator factor to get an Evaluator which can use
CompressedRowSparseMatrix objects for storing the Jacobian.
4. Update the tests for SparseNormalCholeskySolver.
5. Separate out the tests for DynamicSparseNormalCholeskySolver into its
own file.
Change-Id: I2ef7ef8fbfbb4967d0c1ec2068c1c778248fdf5b
When detecting duplicates, it is more efficient to use std::adjacent_find
than it is to use std::unique.
Change-Id: Ib6b4671c10848bb7dd10aa7a1baeffc8c9c825b5
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
- Ensure that, as in the preprocessor, we force num_threads to be 1
if Ceres was compiled without OpenMP to prevent a CHECK() failure
in internal code.
Change-Id: I49d7bdeff81e5bb24aaaa3945018d9d012cd9df9
When a user requests an operation on a parameter block which has
not been added to the problem, we now display a more helpful
error message with more context.
Change-Id: Ia7e54815111eb6375b31ed0d1cddca5917138ae1
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
- Breaking change: Problem::Options::enable_fast_parameter_block_removal
is now Problem::Options::enable_fast_removal, as it now controls
the behaviour for both parameter and residual blocks.
- Previously we did not check that the specified residual block to
remove in RemoveResidualBlock actually represented a valid residual
for the problem.
- This meant that Ceres would die unexpectedly if the user passed an
uninitialised residual_block, or more likely attempted to remove a
residual block that had already been removed automatically after
the user removed a parameter block upon on which it was dependent.
- RemoveResidualBlock now verifies the validity of the given
residual_block to remove. Either by checking against a hash set of
all residuals maintained in ProblemImpl iff enable_fast_removal
is enabled. Or by a full scan of the residual blocks if not.
Change-Id: I9ab178e2f68a74135f0a8e20905b16405c77a62b
These two methods allow the user to associate upper and lower bounds
with individual parameters inside parameter blocks.
Change-Id: I68dc37f20b64408da510ba06b89a4f08df54ddad
CostFunction now uses int32 instead of int16
to store the size of its parameter blocks.
This is an API breaking change.
Change-Id: I032ea583bc7ea4b3009be25d23a3be143749c73e
Calling Problem::Evaluate mutates the state of the parameter blocks.
In particular, depending on the set and order of parameter blocks
passed to the evaluate call, it will change the internal indexing
used by the Program object used by ProblemImpl. This needs to be
undone before Evaluate returns, otherwise the Problem object
is in an invalid state.
To help with testing and debugging in the future, a new method
Program::IsValid has been added which checks whether the problem
has its parameter and residual blocks in the right state.
Thanks to Stefan Leutenegger for reporting this.
Change-Id: I209b486a31433f0cbb58b570047649eca6d42b56
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
The indexing parameter in the parameter block is expected
to be the same as its position in the program. However,
when Solve is called, the parameter blocks are made
members of a new program and the same indexing parameter
is used to store the position of the parameter block
in this new reordered program.
So when the user calls RemoveParameterBlock after calling
Solve, and ProblemImpl checks the invariant on the
indexing parameter it does not match and causes a crash.
The fix is to make sure that before returning from Solve,
the state of the indexing parameter's values are restored
to their original values corresponding to their positions
in the Program object contained in the ProblemImpl object.
Thanks to Simon Lynen for reporting this.
Change-Id: I060745026cd23a688c1fb5e2c9e6053e9ba1c78f
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
Use anonymous namespace for this. Also move some surrounding static
function to this anonymous namespace.
Change-Id: Ie235eb7936976563a9db115ec13c59e6e6869b96
1. Add the ability to evaluate the problem without loss function.
2. Remove static Evaluator::Evaluate
3. Refactor the common code from problem_test.cc and
evaluator_test.cc into evaluator_test_utils.cc
Change-Id: I1aa841580afe91d288fbb65288b0ffdd1e43e827
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
Sameer Agarwal