The LinearSolver factory was creating a NULL linear solver
if only Eigen's sparse linear algebra backend was available.
Thanks to Michael Samples and Domink Reitzle for reporting this.
Change-Id: I35e3a6c0fd0da2a31934adb5dfe4cad29577cc73
If the parameter block size is 1, asking Eigen to create
a row-major matrix triggers a compile time error. Previously
we were handling the case where the number of rows in the
jacobian block was known statically, but the problem is present
when the nummber of rows is dynamic.
This CL fixes this problem.
Thanks to Dominik Reitzle for reporting this.
Change-Id: I99c3eec3558e66ebf4efa51c4dee8ce292ffe0c1
- Previously if options.num_threads > 1 was given to Covariance compiled
without OpenMP, a CHECK() would be triggered in program_evalutor.
Change-Id: Iaade4f5ed5326b0c59a7014c750c41ee026e1124
1. Allow the minimum number of linear solver iterations to be zero.
2. Fix conjugate gradients solver's iteration loop to be sane again.
Change-Id: I8594815fec940c2b30e28eb58ec5d8baacf13dae
1. Fix a build breakage in graph_test.
2. Respect Solver::Options::min_num_linear_solver_iterations in
conjugate_gradients_solver.cc
Thanks to Johannes Schönberger for reporting these.
Change-Id: Ib32e3929bf5d92dd576ae5b53d4d88797095136e
Rename Graph -> WeightedGraph.
Add a new Graph class, which is cheaper to construct and
work with if the weights are not needed.
This cuts down the cost of building the Hessian graph
significantly.
Change-Id: Id0cfc81dd2c0bb5ff8f63a1b55aa133c53c0c869
I got the following error with MSVC:
Syntax error at index 9 in simple regular expression "NumGroups()": '(' is unsupported.
Change-Id: Id1952831d81d3eb5d73bbed8c311914c4c8ab51f
Alternatively, if quiet_NaN is not available on all platforms a workaround would be:
volatile double zero = 0.0;
double x = 1.0/zero;
The 'volatile' is needed to shut up "warning C4723: potential divide by 0".
Change-Id: If2bbdab8540595aa2e0079e1eb6b6fed6d4a6ef7
TrustRegionPreprocessor was not setting Minimizer::Options::is_constrained.
This meant that the line search for bounds constraints was not being
invoked for bounds constrained problems.
And some minor lint cleanup.
Change-Id: I18852cfaf1b33fd90b7d8c196f2063c128126658
Replace SolverImpl with
a. A minimizer specific preprocessor class.
b. A generic Solve function inside solver.cc
c. Presummarize and Postsummarize functions to handle
updates to the summary object.
The existing SolverImpl class was a mixture of the above three
things and was increasingly complicated code to follow. This change,
breaks it into its three separate constituents, with the aims of
better separation of concerns and thus better testability and
reliability.
The call to Solver::Solve() now consists of
1. Presummarize - summarize the given state of the problem and solver
options.
2. Preprocess - Setup everything that is needed to call the minimizer.
This includes, removing redundant parameter and residual blocks,
setting up the reordering for the linear solver, creating the
linear solver, evaluator, inner iteration minimizer etc.
3. Minimize.
4. Post summarize - summarize the result of the preprocessing and the
solve.
Change-Id: I80f35cfc9f2cbf78f1df4aceace27075779d8a3a
1. Base class for preprocessors.
2. A preprocessor for problems that will be solved using
the trust region minimizer.
3. Added sanity tests to the program reordering options
for Schur type linear solvers.
4. Tests for the TrustRegionPreprocessor.
Change-Id: I88cd926f0053bbbf2bd6b11e03ec55b8bf473cf1
This is a intermediate change to clean things up
in preparation for a broader refactoring of the SolverImpl.
Essentially we are replacing raw pointers in Minimizer::Options
with shared_ptr objects. For now this only makes things a bit
more complicated looking inside solver_impl.cc, but going
forward this will lead to considerable simplifications in
tracking ownership of various pointers.
Change-Id: I21db8fc6763c29b0d15e834d7c968a0f514042a0
Ensure that when a new problem object is constructed for validing
gradients, the parameter blocks have their data pointers point to
the user's parameter blocks.
We used to do this inside solver_impl.cc, but doing this at
construction is the right thing to do.
Change-Id: I3bfdc89bb0027c8d67cde937e8f2fa385d89c30c
The instrumentation revealed that EIGEN_SPARSE can be upto
an order of magnitude slower than CX_SPARSE on some bundle
adjustment problems.
The problem comes down to the quality of AMD ordering that
CXSparse/Eigen implements. It does particularly badly
on the Schur complement. In the CXSparse implementation
we got around this by considering the block sparsity structure
and computing the AMD ordering on it and lifting it to the
full matrix.
This is currently not possible with the release version of
Eigen, as the support for using preordered/natural orderings
is in the master branch but has not been released yet.
Change-Id: I25588d3e723e50606f327db5759f174f58439e29
Simplifying some of the template handling, and remove the use
of SelfAdjointView as it is not needed. The solver itself takes
an argument for where the data is actually stored.
The performance of SparseNormalCholesky with EIGEN_SPARSE
seems to be on par with CX_SPARSE.
Change-Id: I69e22a144b447c052b6cbe59ef1aa33eae2dd9e3
SPARSE_NORMAL_CHOLESKY and SPARSE_SCHUR can now be used
with EIGEN_SPARSE as the backend.
The performance is not as good as CXSparse. This needs to be
investigated. Is it because the quality of AMD ordering that
we are computing is not as good as the one for CXSparse? This
could be because we are working with the scalar matrix instead
of the block matrix.
Also, the upper/lower triangular story is not completely clear.
Both of these issues will be benchmarked and tackled in the
near future.
Also included in this change is a bunch of cleanup to the
SparseNormalCholeskySolver and SparseSchurComplementSolver
classes around the use of the of defines used to conditionally
compile out parts of the code.
The system_test has been updated to test EIGEN_SPARSE also.
Change-Id: I46a57e9c4c97782696879e0b15cfc7a93fe5496a
The loss functions that ship with ceres can sometimes
generate a zero first derivative if the residual is too
large.
In such cases Corrector fails with an ugly undebuggable
crash. This CL is the first in a series of fixes to
take care of this.
We clamp the values of rho' from below by
numeric_limits<double>::min().
Also included here is some minor cleanup where the constants
are treated as doubles rather than integers.
Thanks to Pierre Moulon for reporting this problem.
Change-Id: I3aaf375303ecc2659bbf6fb56a812e7dc3a41106
- Warning type generated is unused-but-set-variable, not unused-variable
and the corresponding "local variable is initialized but not
referenced" MSVC warning.
Change-Id: I716fd6a87cc91533bc862b2ef932601c8857818d
- Eigen 3.2.0 emits an unused variable warning from Ordering.h
#included by Eigen/SparseQR which prevents Ceres compilation due
to -Werror.
- As Eigen 3.2.0 is still in widespread use, we explicitly disable
the warning only around the inclusion of Eigen/SparseQR.
Change-Id: I48ce905ef6a22bc1b06f9e5bed328bd315f407f0
Sparse Cholesky factorization is not rank revealing. Therefore
this algorithm cannot reliably tell when the Jacobian matrix is
rank deficient or so poorly conditioned that the covariance matrix
cannot be estimated.
Making things worse, this algorithm works on the normal equations,
which makes the conditioning problem much worse.
This change, deletes the SPARSE_CHOLESKY algorithm in the covariance
estimation code. Also to make the naming consistent, it renames
SPARSE_QR -> SUITE_SPARSE_QR
so that it parallels EIGEN_SPARSE_QR.
Also, since we now have EIGEN_SPARSE_QR, we can default to using
it when SuiteSparse is not available instead of DENSE_SVD, which
generally speaking should only be used by folks who are dealing
with small rank deficient jacobians.
Change-Id: I8b134c7e8a2e86ca374371f185b19f1c3e74349c
For smaller problems Eigen is faster than SuiteSparseQR. This has been
tested with Eigen 3.2.1. Below are detailed timings. Problem 1 is the
smallest and problem 3 is the largest. The timings below are:
mean +- standard deviation.
Problem 1:
Eigen 0.0009218 +- 0.0002755
SuiteSparse 0.001406 +- 0.001610
Problem 2:
Eigen 0.002338 +- 0.001005
SuiteSparse 0.001910 +- 0.0004513
Problem 3:
Eigen 0.005455 +- 0.001759
SuiteSparse 0.002411 +- 0.0004974
Detailed problem descriptions:
Problem 1 size:
Original Reduced
Parameter blocks 533 54
Parameters 368 104
Effective parameters 1201 94
Residual blocks 233 77
Residual 1194 258
Problem 2 size:
Original Reduced
Parameter blocks 573 84
Parameters 1458 184
Effective parameters 1281 164
Residual blocks 263 107
Residual 1314 378
Problem 3 size:
Original Reduced
Parameter blocks 613 114
Parameters 1548 264
Effective parameters 1361 234
Residual blocks 293 137
Residual 1434 498
Change-Id: I884a67e2f728fe2992812148d82ccf5f27864fd7
- Previously if miniglog was being used (on a non-Android system), we
compiled it into a separate library, against which Ceres then linked.
- This was unsatisfactory as it required miniglog being built as a
static library when building Ceres as a Windows DLL, because miniglog
did not use the dllexport/dllimport statements, whilst for other
platforms when building Ceres as a shared library, miniglog needed to
be compiled as a shared library.
- We now compile miniglog into Ceres on all platforms, not just on
Android.
- miniglog now uses the CERES_EXPORT macro to support Windows DLLs.
This means that miniglog now depends on Ceres' internal/port.h (and
thus internal/config.h) which define the CERES_EXPORT macro and
control its behaviour respectively.
- miniglog now also uses localtime_s, not localtime on Windows.
Change-Id: Ia55b9af8b4e6decf067eab92f0a5c2d14358a1e9
Move all the program reordering programs into their own file.
Also split the reordering routines for SPARSE_NORMAL_CHOLESKY
into individual library dependent routines.
Also get rid of RemovedFixedBlocksFromProgram.
Change-Id: Ie969f529e6d20dded9da021b9df1a040e08287c1
CreateReducedProgram is a safer API, reduces the possibility of
memory leaks and produces valid programs.
Change-Id: I094d53d207fced970a4d9ea0b66cdb09ce5f0657
A number of typos in solver.cc which were hidden behind ifdefs
and were only revealed when building under android.
Change-Id: I89cbe8056da071479d2d1a251a8919b0be1f1cd4
Program::RemoveFixedBocks will happily drop all fixed parameter
and residual blocks. So if it is called on the one and only copy
of a program, like it was being called in the tests, this will
result in a memory leak because we would have lost track of the
fixed parameter and residual blocks.
This is not a problem in actual usage since CreateReducedProgram
will first create a copy of the program and then remove the fixed
blocks from it. But in the tests, we were creating a ProblemImpl
and then calling RemovedFixedBlocks on the underlying program
object causing a memory leak.
The fix to make a copy in the tests and then work on that. I
have also added a warning in program.h
Change-Id: I03a5f7a7f5453aec848451a5c0ace4b065f71e9b
Inner iterations require specific constraints on parameter
block orderings. The creation and validation routines for
these orderings are not static methods in CoordinateDescentMinimizer.
Change-Id: Ifc89491c9a8672e08523191b74b53058cbfa1db3
Move functions that determine alternatives to Schur type linear
solver and preconditioners into the LinearSolver and Preconditioner
interfaces.
Change-Id: Iae900afb7db17cdbeb7753497005a48c3144e2d7
Sameer Agarwal