1. Add abseil-cpp as a submodule. We are tracking the latest LTS
release, which is lts_2024_01_16.
2. Replace glog/gflags with absl::log and absl::flags.
3. Remove miniglog
4. Also take a whack at making the bazel build work with
abseil-cpp and gtest.
There are a number of TODOs in this CL that still need to be resolved.
Change-Id: I39355ed7d61375be4ebcbc8596d9cc70acc1c678
1. Add a version history
2. Update copyright years across the code base
3. Run format_all.sh
4. Update version strings from 2.1.0 to 2.2.0 in the docs and
elsewhere.
Change-Id: I46d8d479d54bd6002d532785e67342106e73c9ac
These methods were historically poorly named and every time I read code
I get confused whether they are just multiplying or multiplying and
adding. Clarifying them also gives us the changce to introduce
RightMultiply and LeftMultiply methods in the base class which will
simplify a number call sites in a subsequent CL.
Fixes https://github.com/ceres-solver/ceres-solver/issues/855
Change-Id: Ice4fb483f1acd02527a6dd753ef0c5a66037f4b0
* Split `CERES_NO_METIS` into two defines: `CERES_NO_PARTITION` and
`CERES_NO_METIS`. The former refers to METIS support in SuiteSparse,
the latter to the Eigen's MetisSupport module. This enables the use of
sparse matrix reordering independent from SuiteSparse.
* Run Linux, macOS, and macOS Github workflows with METIS enabled
SuiteSparse.
Fixes#808
Change-Id: I5076b7e1268d32cc3e7e56650edcbaf7fb3b59ce
Eigen provides all the functionality that we need from CXSparse
with a more liberal license.
I will update the documentation in a follow up CL.
Change-Id: I0b9fd8be3c27754cc2986cc0e06595c8b3fdec0b
1. Generalize SuiteSparse::AnalyzeCholesky and
SuiteSparse::BlockAnalyzeCholesky from just doing AMD to taking
OrderingType as an argument and using that to determine whether
AMD & Nested Dissection algorithms are used for computing the
fill-reducing ordering or a natural ordering when computing
the symbolic factorization.
2. Remove AnalyzeCholeskyWithNaturalOrdering.
3. Replace and generalize SuiteSparse::BlockAMDOrdering with
SuiteSparse::BlockOrdering which also takes OrderingType as an
argument. Same for SuiteSparse::ApproximateMinimumDegreeOrdering
and SuiteSparse::NestedDissectionOrdering by
SuiteSparse::Ordering.
4. Remove LinearSolver::Options::use_postordering and replace it
with LinearSolver::Options::ordering_type.
5. Replace Preconditioner::Options::use_postordering and replace it
with Preconditioner::Options::ordering_type.
6. Add NESDIS to OrderingType. With the above changes, the linear
solvers can now use Nested Dissection once this information
is piped through the nonlinear solver.
Change-Id: Ib8e93fbf34ae2981bf2ac54dcda9e25c7c213790
covariance.h was using SUITE_SPARSE even when SUITESPARSE
was disabled because it did not have config.h included in it
so it did not see that CERES_NO_SUITESPARSE was defined.
Add more config.h includes to files that are using these
configuration macros.
Change-Id: I6b1d2c2bd9e559de40a6332cd6be85ad4da3377b
- Change formatting standard to Cpp11. Main difference is not having
the space between two closing >> for nested templates. We don't
choose c++14, because older versions of clang-format (version 9
and earlier) don't know this value yet, and it doesn't make a
difference in the formatting.
- Apply clang-format to all (non generated) internal source files.
- Manually fix some code sections (clang-format on/off) and c-strings
- Exclude some embedded external files with very different formatting
(gtest/gmock)
- Add script to format all source files
Change-Id: Ic6cea41575ad6e37c9e136dbce176b0d505dc44d
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
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
Sameer Agarwal