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
Build with documentation fails if the required 'sphinx rtd theme' is
not available. Check if dependency is installed before building with
documentation.
Add Python3 as requirement for building documentation.
Change-Id: I5edc5d7374864990e625a5efb358f5a23b3c50fe
- update links to cmake docs to version 3.5
- highlight difference between dependencies with and without custom
find modules
- point out removal of CERES_INCLUDE_DIRS
- point out that TBB might be linked if SuiteSparseQR is found
- added 'Migration' section
- fixed typos
Change-Id: Icbcc0e723d11f12246fb3cf09b9d7c6206195a82
Linux:
- Remove workaround for Ubuntu 14.04, which is EOL. libsuitesparse-dev
seems to come with a shared library on 16.04 and later, so linking
to a shared build of ceres doesn't seem to be an issue any more.
- Add missing libgflags-dev.
macOS:
- OS X is now called macOS.
- Update homebrew link.
- Mac homebrew the preferred method of installation.
- Fix OpenMP instructions.
- Remove reference to homebrew/science. Everything is in core.
- Add missing gflags.
Change-Id: I633b3c7ea84a87886bfd823f8187fdd0a84737c9
Alex Stewart