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
* Make sphinx_rtd_theme a find module component to avoid hard-wiring it
into the module and allowing to report the theme in case it is missing
using the standard CMake package mechanism.
* Adjust find module cache variables names case to match the find module
name.
* Also report sphinx-build version for completeness.
* Invoke the find module only once. Calling find_package on the same
module is not needed.
Change-Id: I9d1bf0fcc0d44b9b37e624128812f348c5442ada
Given we no longer support Ubuntu 18.04 due to packaged GCC lacking
C++17 support we can bump the minimum required CMake version to the one
provided by Ubuntu 20.04 which is CMake 3.16. Consequently, this allows
to drop some of the legacy CMake logic.
Change-Id: I1f05d4c5681d10aa7faa0800ef4a803be2f5b7dd
This was an ill-advised and complicated to interpret option
which offers nothing particularly useful.
Change-Id: Ia7741ed62ef977c96fa52299a884e404bee659ac
With this change we can drop the complicated/conditional handling
around CAMD and assume that it is always available.
Change-Id: I93e1da676fb75817f79824b8b2b6549d03f278b0
1. Update the cff file to be more inclusive.
2. Update the BibTeX entry in index.rst to match the one generated
by GitHub.
Change-Id: I26d031b2128d1d4330623bcdace284ca9ffce9e1
The last item in the 'New Features' section restarts the enumeration
because the indention of the previous subitem is one space short.
Change-Id: Ifa2873d3e2ddd6bac5034b48207775019ef1c462
These changes allow the use of a SuiteSparse CMake package from
https://github.com/sergiud/SuiteSparse that allows native compilation of
SuiteSparse using CMake on a variety of platforms Packages generated
using official SuiteSparse makefiles can still be used without
modifications. The find module remains agnostic to specific CMake
package implementation.
CMake packages have the advantage that they are self-contained and
relocatable. The latter is particularly useful in cross-compilation
scenarios.
Fixes#728
Change-Id: I089d5c6f87c05b1530a5ab9a36dff2fcbe82d13d
In many cases, manifolds stored in ProductManifold have a default
constructor which can simplify ProductManifold initialization even
further. Allow default construction of ProductManifold in this case.
Change-Id: I29b2612870c02232556688019a77049709684a55
Since the number of manifolds used to initialize ProductManifold and
their types are known at compile-time, it is possible to avoid storing
pointers to the base class as required by a homogeneous, currently
dynamically sized container. Instead, we can use std::tuple<> as a
heterogenous container with the number of elements fixed at compile-time
that allows us to store the concrete manifold realizations.
The advantage of this approach is that we can bypass the vtable when
iterating over each manifold within ProductManifold. The indirection is
invoked only once while accessing the ProductManifoldImpl members.
Additionally, potential dynamic memory allocations by a std::vector can
be completely avoided. This makes the ProductManifold implementation
more efficient both in memory and runtime.
Change-Id: Ic71b0c175ab726f8992e9703f7666bca477baf19
This brings it in line with other manifolds like SphereManifold
and LineManifold, where the user has the choice to specify the size
of the manifold at compile time or runtime.
Most of the time the size is known at compile time so this will
speed up the common case.
Change-Id: I0c7ff8b7a9a64a81203eb11afc074874e208815a
1. Fix a stupid error in types.cc
2. Update documentation for Solver::Options::dense_linear_algebra_library_type
3. Add a note to installation.rst to update the installation docs.
4. Mention GPU acceleration in features.rst
Change-Id: Id63202ff090e23bbb211d2ee458559fb8046281d
Add [[deprecate]] notices to everything LocalParameterization
related.
Make sure that Ceres can be compiled without triggering
deprecation warnings.
Update the documentation:
a. Add deprecation notices.
b. Document interaction between LocalParameterization and Manifold
coexisting in the Problem.
c. Add documentation for Manifold(s)
Change-Id: Ie4ad48963c83fded86e533c8c60561af402fbaff
- Also adds documentation of mixed precision solves to Sphinx docs.
- Fix reference to Sphinx theme used (RTD not better).
- Fix NOTE syntax in use_explicit_schur_complement Sphinx docs.
Change-Id: I7bdac0f07eb737f49b05e3fcaa3eebd087355d2d
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
This has been a long requested feature so that users can minimize
functions using numeric differentiation.
As part of this, I have also redone rosenbrock.cc, which now has three
variants.
rosenbrock.cc now uses automatic differentiation.
rosenbrock_numeric_diff.cc uses numeric differentiation.
rosenbrock_analytic_diff.cc uses analytic derivatives.
This is analogus to how the helloworld example code is structured.
The tutorial for GradientProblemSolver has also been updated to reflect
this.
https://github.com/ceres-solver/ceres-solver/issues/691
Change-Id: Ib0fb9e35127fe4c8299d4793bea3558722c70dd7