- Microsoft deprecated the POSIX Bessel functions: j[0,1,n]() in favour
of _j[0,1,n](), it appears since at least MSVC 2005:
https://msdn.microsoft.com/en-us/library/ms235384(v=vs.100).aspx.
- As this occurs in jet.h (templated public header), although Ceres
suppresses the warning when it itself is built (to suppress a warning
about the insecurity of using std::copy), it will crop up again in
client code (without this fix) unless it is explicitly suppressed
there also.
- Raised as Issue #190:
https://github.com/ceres-solver/ceres-solver/issues/190.
Change-Id: If7ac5dbb856748f9900be93ec0452a40c0b00524
TrustRegionMinimizer evaluates the size of the step
taken in the ambient space, where as the LineSearchMinimizer
was using the norm in the tangent space. This change fixes
this discrepancy.
Change-Id: I9fef64cbb5622c9769c0413003cfb1dc6e89cfa3
- As noted in Issue #193 (in that case for GCC 6), Ceres' use of -Werror
when compiling on *nix can prevent compilation on new compilers that
add new warnings and there is an inevitable delay between new compiler
versions and Ceres versions.
- Removing the explicit use of -Werror, and relying on indirect
verification by maintainers should fix build issues for Ceres releases
on newer compilers.
Change-Id: I38e9ade28d4a90e53dcd918a7d470f1a1debd7b4
- Users can now specify particular components from Ceres, such as
SuiteSparse support) that must be present in a detected version of
Ceres in order for it to be reported as found by find_package().
- This allows users to specify for example that they require a version
of Ceres with SuiteSparse support at configure time, rather than
finding out only at run time that Ceres was not compiled with the
options they require.
- The list of available components are built directly from the Ceres
compile options.
- The meta-module SparseLinearAlgebraLibrary is present if at least
one sparse linear algebra backend is available.
Change-Id: I65f1ddfd7697e6dd25bb4ac7e54f5097d3ca6266
- Previously we were auto-detecting a "64" suffix for the install path
for the Ceres library on non-Debian/Arch Linux distributions, but
we were installing CeresConfig.cmake to an architecture independent
location.
- We now install CeresConfig.cmake to lib${LIB_SUFFIX}/cmake/Ceres.
- Also make LIB_SUFFIX visible to the user in the CMake GUI s/t they can
easily override the auto-detected value if desired.
- Reported by jpgr87@gmail.com as Issue #194.
Change-Id: If126260d7af685779487c01220ae178ac31f7aea
The README.md was woefully out of date, as it was advertising
Ceres Solver as just a non-linear least squares library.
Change-Id: I9a58fb8b63c08ee3852ffbae955e2ca8c90cd6d9
The norm comparison in QuaternionParameterizationHelper is exact
but that leads to numerical precision problems and test failures
as reported by Nicu Stiurca.
https://github.com/ceres-solver/ceres-solver/issues/198
Change-Id: I45f42f0373770408ddeee0b4c9d162e619f8d445
Otherwise, it will fail on Python 3 with:
"UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position
7690: ordinal not in range(128)"
We have to use io.open() instead of open(), because open() does not
accept the encoding on Python 2.
Change-Id: I77b6552491e8de01d79a26d2f146ddbd968cce49
on a ceres built without SuiteSparse support.
This is only a minor issue, up until now this case would have been handled by
the "default" case of the switch
Change-Id: Ib4568eb827dbf0e8e8d618a5bc8cd379a3c42c42
- Previously we were disabling the CXX11 option when WIN32 was defined,
which it can be on both MinGW & CygWin, even though the compilers
there can support the -std=c++11 option.
- Now we disable the CXX11 option only when the compiler used is MSVC.
Change-Id: I68ebcf0a4241afe93892a3c6f79cdd98887e785a
- This could result in potentially confusing output if dependencies
were found with the QUIET option: "XXX not found due to ...", followed
by "found <part of> XXX".
- If find_package() was called with REQUIRED, then a FATAL_ERROR was
triggered in the xxx_not_found() macros, resulting in early
termination.
Change-Id: Ibf59afd10067b9debd1a5e15f735a41b61bed52e
This variable should be initialized before the decision to
perform inner iterations are performed.
Change-Id: Ic80e2d5284ecc67eaed1859be009b1a4d18bf76b
1. Break up the monolithic loop in TrustRegionMinimizer::Minimize
into a number of more easily described and analyzed subfunctions.
2. Break out the logic for evaluating the quality of a Trust Region
step into its own object - TrustRegionStepEvaluator.
Change-Id: I08580ecac074cfd74c096cb8e4880cbda3d48296
- va_copy() was defined in the C99 standard, but did not appear in the
C++ standard until C++11. If the C++ standard is not specified,
both GCC & Clang will define va_copy(), even though strictly speaking
they should not. However, if the C++ standard is explicitly specified
to something < C++11 (e.g. -std=c++03) then va_copy() will NOT be
defined.
- Now, if va_copy() is not defined, we either define our own version
on non GCC/Clang compilers (as before for MSVC alone), and use the
internal __va_copy() version on GCC & Clang, which does exist.
Change-Id: I0224f7fa6aae060dee2287782b1cad767c244d3c
This is the right thing to do since the CMake files contain target
specific information - share is only for target-independent files.
Without this patch, the CMake files will collide on distributions
that allow to install for multiple targets in parallel (e. g. on
Exherbo).
Change-Id: Iac17af63b9f9b25d0ca400c77c2b2e0e8a51196f
This is needed for multiarch layouts where the prefix is /usr/${host}
but where arch-independent files are installed to /usr/share.
Change-Id: Icec01f8ea927594b4edb26997d6384e478415999
Computing the covariance matrix for a number of parameter blocks
previously required adding all parameter blocks to the computation and
subsequently assembling the matrix by concatenating all the blocks.
This patch adds the computation of the covariance matrix for a vector
of parameter blocks. All covariance block pairs are added automatically
and the resulting covariance matrix is assembled in the order the
parameter blocks appear.
Change-Id: I3b70c63f16862adc23a1d7fb7a21dde4e68abe9a
NIST recommends greater than 4 digits rather than greater than
or equal to 4 digits to declare that the solve was successful.
Change-Id: I5c65e6e791508b95b692c23dafd3833d73cd0487
Print information about the fill-in when using Eigen to perform
Simplicial sparse Cholesky factorization.
Change-Id: I09013b7f4ed2f6c55ae8ce8922447e23d63580a8
When detecting duplicates, it is more efficient to use std::adjacent_find
than it is to use std::unique.
Change-Id: Ib6b4671c10848bb7dd10aa7a1baeffc8c9c825b5
I169b637a1e2a106956b536c41d6a514a266e7cc0 marked Jets (in C++11) as
aligned to 16 bytes, and enabled Eigen vectorization. However, to
implement this, we added Eigen includes to port.h.
Turns out this broke some other tricks Ceres uses (redefining Eigen
constants for better performance), so we don't want to do that. Move
most of the implementation to jet.h where it is safe.
Change-Id: I47c6fc4180db1ff674bc660723dd5a2b84254e0d
We currently don't align the infinitesimal part of a Jet to a 16-byte
boundary (and thus force Eigen to avoid using SSE ops)--as a member of a
larger struct, we couldn't guarantee Jets would be allocated on
appropriately-aligned boundaries. However, C++11 adds better support
for requesting alignment: we can use it to guarantee the members will be
properly aligned, and tell Eigen to vectorize.
There is a significant gotcha here: the standard gives wide latitude to
implementations as to which alignments they choose to support. If we
ask for 16 and the system only supports 8, we may have misaligned
Jets. So we test (using alignof(std::max_align_t)) that the current
system supports 16-byte aligned values; if not, we fall back to the
current solution.
Two other small notes:
- This is obviously gated on C++11 support, and
thus we put the logic in port.h and export some useful #defines.
- GCC 4.8.x has a
bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019) that has
max_align_t in the wrong namespace. This will not be a problem with a
modern GCC, but add a small workaround since many systems still ship 4.8.
This results (on a x86 workstation) in a 60% speedup in Jacobian
evaluation on bin/simple_bundle_adjuster problem-16-22106-pre.txt.
Change-Id: I169b637a1e2a106956b536c41d6a514a266e7cc0
Parameter blocks that are not associated with any residual block
lead to structurally zero columns in the Jacobian. The covariance
computation algorithm was only paying attention to structural
sparsity caused by constant parameter blocks but not free parameter
blocks.
This patch fixes this, by iterating over the residual blocks in
the problem and collecting all the parameter blocks in use.
The tests for ComputeCovarianceSparsity are also extended to include
the case where there are constant and free parameter blocks.
Thanks to Wannes Van Loock for reporting this.
Change-Id: Ic298a6e93c53f2f95fb69105397a87200738a2b0
Accumulate the number of steps of the line search algorithm
and report it as part of Summary::FullReport.
Change-Id: I1de12784009a3e08f2a2c2aff5085d57a3c73828
- Previously we had the Ceres version defined in two places, one in
include/ceres/version.h, and one in the main CMakeLists.
- Now the main CMakeLists reads the Ceres version directly from
version.h, as does the make_release script, so that we have a single
place (version.h) in which the current Ceres version is defined.
Change-Id: Ie80aa7d38f5b576d3ed4d6109dd699f565c91027
This commit fixes a bug related to the computation of covariance blocks
in the tangent space for constant parameter blocks, causing out of
bounds memory access.
Change-Id: Iaeee7992405fcaaae6086612798e96f2e10ebc5c
1. Add answers to a number of FAQs.
2. Add a note to the documentation for NumericDiffCostFunction that
NumericDiffOptions needs to be documented and mentioned.
3. Update the docs for Solver::Options::numeric_derivative_relative_step_size
to indicate that this setting only applies to the gradient checker.
4. Remove deprecated constructors from NumericDiffCostFunction and
DynamicNumericDiffCostFunction.
Change-Id: If8fc011b2a5996dbc2c51268aa477550ed014a1c
Sameer Agarwal