1. Add schur_templates.cc to Android.mk
2. When detecting the Schur structure of the Jacobian,
the check for whether linear solver being used is indeed
of Schur type or not, should use the LinearSolver::Options
struct created and populated by the preprocessor rather than
depending on the value in the input Solver::Options. The reason
is that the preprocessor may change the linear solver type
depending on the lack of a Schur structure in the problem.
Change-Id: I6f018f6817c05d704409181c7b1e25155528ab84
1. Refactor the python code that generates the template specializations
to remove code duplication.
2. Improved the logic for template specialization selection where
Eigen::Dynamic now serves as a wildcard.
3. Added schur_templates.h/cc which allows querying the set of available
template specializations without instantiating a linear solver.
4. Added Solver::Summary::schur_structre_given and
Solver::Summary::schur_structure_used and expose them in
Solver::Summary::FullReport for better performance debugging.
5. Updated the templates with newer dates and some minor comments cleanup
which lead to the the template specializations to be re-generated.
Change-Id: Iaf3c6f714353597899916c300465da01f151c3de
- ScalarBinaryOpTraits was introduced in Eigen 3.3, and thus breaks
compilation of Ceres for Eigen versions < 3.3.
- Reported as issue #252 by AustinDeric:
https://github.com/ceres-solver/ceres-solver/issues/252
Change-Id: Ie9b7dace17709c348b18b297f2d5306b054ce4b0
Changes in Eigen's implementation for FullPivLU significantly
degraded the performance of the line search as reported by Weiguang.
We do not completely understand what is going on, as Eigen's changes
seem sane. So for now, this change explicitly works around the
changes made by Eigen to restore the performance of the line search.
Figuring out the underlying problem and fixing it remains an open
issue.
https://github.com/ceres-solver/ceres-solver/issues/248
Change-Id: I9993d73a09dc990ab567ce6bc447f16eac74abec
This commit extends the use of Jets with Eigen matrices and arrays
by enabling the use of binary operators (such as scalar addition,
multiplication, as well as matrix multiplication) when one Eigen
matrix/array is of type Jet and the other is a scalar type. This
should increase performance since Jet types have optimized
scalar-to-jet binary operations.
Change-Id: Ia756064845d845cefcf0abb16d366331d2824b52
Binary operations between Jets and doubles are well defined
and should not require an explicit conversion to Jets to work.
This was an oversight earlier and lead to overzealous conversions
all over our in our example code.
Change-Id: I1799770818e136edfc0a5802d86037ce9aec4923
Below fixes are required to compile Ceres as a dynamic library using
MSVC.
1. Added CERES_EXPORT to EigenQuaternionParameterization.
2. Removed CERES_EXPORT from CubicInterpolator and BicubicInterpolator.
EigenQuaternionParameterization has its source embedded in ceres.dll
whereas Cubic+BicubicInterpolators are defined in the header file and
therefore do not require __declspec(dllimport).
Change-Id: Idd1f387890c36aab51a1a4177ea7c06933b96f39
- MSVC deprecated the standard POSIX names for Bessel functions in
favour of underscore prefixed versions.
- Previously we were checking for the presence of the newer underscore
functions via a macro, which fails as the functions are not defined
as macros.
- Now we check via a check_cxx_source_compiles() if the newer underscore
prefixed versions exist when compiling on MSVC and use a new Ceres
configuration #define to switch on their presence in jet.h
Change-Id: I430880bde2981d12f4d03dbc94d903b9842e887e
ResidualBlock evaluation has logic to ensure that CostFunction
should always fill out the residual and jacobian arrays completely
by using a special value to pre-populate these arrays.
This works for CostFunctions with analytical Jacobians but not for
AutoDiffCostFunction and NumericDiffCostFunction Jacobians.
There is no way to fix this for NumericDiffCostFunctions without
introducing significant performance penalties but the residual
evaluation fails, which should be enough to catch such errors.
For AutoDiffCostFunction the way the Jets are default initialized
was sidestepping this check. So now, the Jet that is used to
capture the output residuals is now initialized with
kImpossibleValue, which will ensure that if the user forgets
to fill all output fields, it triggers an evaluation error.
This change required that ceres::internal::kImpossibleValue be moved
out of array_utils.h/cc to types.h.
Change-Id: I35bb0946cf0785a5d43c7b5459a2272848fb2a9b
- glog has a bug in its CMakeLists.txt whereby it uses ‘google-glog’ as
its project() name in its CMakeLists.txt, but exports itself as ‘glog’
which results in an install prefix on Windows which contains
‘google-glog’ instead of ‘glog’ which breaks find_package(glog).
This has been raised as a glog issue here:
https://github.com/google/glog/issues/149.
- We now force find_package(glog) to search glog using both
‘google-glog’ (for Windows) & ‘glog’ (for all other OSs).
Change-Id: I6c0edccdec405200eaa0fea1476b574e73bd3f14
MSVC requires using google::GLOG_WARNING, but this breaks the build
inside google. So add a MSVC specific ifdef to guard against it.
Change-Id: I3509bb3fd2c01722a1c76545b57d2bf0224f6d6e
- Eigen versions < 3.3 only supported SIMD instructions that required
16-byte alignment (SSE), whereas Eigen >= 3.3 also supports AVX
instructions which require 32+-byte alignment.
- Previously we only ever requested 16-byte alignment for Jets (if >=
C++11 was enabled) which resulted in Eigen assertions being triggered
on some compilers as reported as Issue #251:
https://github.com/ceres-solver/ceres-solver/issues/251.
- Now we use Eigen’s EIGEN_MAX_ALIGN_BYTES macro, defined in Eigen >=
3.3 to specify the byte alignment for Jets when C++11 is enabled for
Eigen >= 3.3. For Eigen versions < 3.3, we maintain the previous
behaviour of 16.
Change-Id: I749af7a70ae794e0c2a59301128db781e338422c
- When built with CMake on Windows, the default install prefix
will be C:/Program Files/<PROJECT_NAME> (instead of /usr/local on
Linux / OS X.
- Due to an upstream change in Eigen >= 3.3, the project name for Eigen
changed to Eigen3 from Eigen, thus changing the default install
location.
- glog, uses the project name “google-glog”, thus when it is build with
CMake, this becomes it’s default install path instead of just glog
when built with other tools.
- This patch adds both of these paths to the default search list on
Windows.
Change-Id: I987b502fed0f6e685c504fd47fd504307aad8bef
- This protects against a client project which invokes
find_package(Ceres) after having called find_package(Foo) with their
own version of FindFoo.cmake which conflicts with Ceres’ exported
version and defines FOO_FOUND, but not the other variables Ceres’
FindFoo.cmake is expecting which can break the detection logic.
Change-Id: I9fe7bfa8a34bb58b09ffe34446da973912cf5587
1. Section title changes.
2. Moving the glog discussion into installation.rst
3. Re-working the faqs into two separate chapters.
Change-Id: I95dd25bace50f0f9077ef114504999190686963e
- If gflags was built & exported with CMake but glog was not, but both
were found then as we now make gflags a public dependency of Ceres if
both it and glog are found, the *name* of the exported gflags CMake
target (gflags-shared or similar) will appear in CERES_LIBRARIES.
- However, as imported targets are not re-exported, this results in a
linker error when compiling client code, as the name of the exported
gflags target is not known to CMake, it assumes it is a library name,
which it is not.
- Confusingly, if glog was built with CMake, this problem would not
occur, as in that case glog’s CMake target would bring in gflags’.
- Now we explicitly call find_package(Gflags) in CeresConfig.cmake if
Ceres was built with gflags as a public dependency (via glog).
Change-Id: I5cc9483a1fae50f4e9e3a8fbba491b645fd45db6
- Previously we were not listing gflags as a public dependency of Ceres
if it and glog were found (and MINIGLOG was not being used). This
does not reflect that if glog was compiled with gflags then it will
#include gflags/gflags.h in glog/logging.h, thus making gflags a
public dependency of anything linking against glog.
- On *nix OSs if glog/gflags are shared libraries this did not result
in a link error when compiling Ceres as the gflags symbols were
indirectly resolved. However, on MSVC this is not the case, and this
could result in unresolved gflags symbol link errors when compiling
Ceres.
- Now we add gflags to the list of public Ceres dependencies if both
glog and gflags are found (and MINIGLOG is not enabled).
Change-Id: I5ce6038fa816781cc81b378522068dc563d29c51
- The latest version of glog supports building with CMake, in which case
it exports itself via CMake as a target that contains important meta
information such as Windows-specific compilation definitions.
- This patch updates FindGlog.cmake such that it can optionally use
an exported glog target if one exists, if not it will fall back to
the current approach whereby the glog components are found manually.
This behaviour (and the implementation) is very similar to that of
FindGflags.cmake.
Change-Id: Idfb5f49c1b457707029bff52068f58237c0e285d
- GLOG_NO_ABBREVIATED_SEVERITIES is the default on Windows, in which
case google::WARNING is not defined.
- Remove Ceres-specific redefinition of WARNING in mock-log.h fork
in place of using non-abbreviated severity in the one place in
levenberg_marquardt_strategy_test where ScopedMockLog is actually
used.
- Remove unnecessary dependency of gradient_checking_cost_function_test
on ScopedMockLog.
Change-Id: I9fb540f638037b6015fd264cfc618c9d60f5686c
- MSVC does not expose standard math constants, such as M_PI in <cmath>
or <math.h> unless _USE_MATH_DEFINES is defined prior to their
inclusion: https://msdn.microsoft.com/en-us/library/4hwaceh6.aspx.
- Use CMake to ensure that this is #defined when both Ceres and the
examples are compiled, even though it should only be an issue for the
examples where M_PI is used.
Change-Id: I67af75b100b8138a65514273d23bfe445d92652c
- gflags_report_not_found() calls gflags_reset_find_library_prefix()
and we only reset CMAKE_FIND_LIBRARY_PREFIXES when performing a manual
search for gflags, but gflags_report_not_found() is also used
before the manual search when searching for an exported gflags target.
- As such, it was possible that we could have cleared
CMAKE_FIND_LIBRARY_PREFIXES rather than reset it if
gflags_report_not_found() was invoked during the exported target
search.
- This patch prevents this possibility by verifying that the cached
version of CMAKE_FIND_LIBRARY_PREFIXES exists before updating it.
Change-Id: I07528ae5f197a366c7da342196b3e977f9a1fc93
- alignas(0) should be ignored, however it results in a build error on
GCC, so instead default to the alignment of double in Jets if
we cannot align to 16-byte boundaries on the platform, but are
compiling with C++11.
Change-Id: I2e54c69516ea2e1447a8bdc138b2dd70050c6dad
- As per Andrew Hunter’s comments in the commit which added Jet
alignment when using C++11 here:
https://ceres-solver-review.googlesource.com/#/c/7100, there is wide
lattitude in the standard about what the maximum supported alignment
can be.
- Previously, we were forcing the alignment to 1, if the value of
alignof(std::max_align_t), which we use as a proxy for the maximum
supported alignment on the platform, was < 16.
- An alignment of 1 is not valid for Jets, as it would weaken the
natural alignment of the types within a Jet, which would typically be
4 (32-bit systems) or 8 (64-bit systems), thus resulting in a compiler
error.
- This was reported as issue 235 for Clang 3.8 on i386:
https://github.com/ceres-solver/ceres-solver/issues/235.
Change-Id: Ie39e5499c64f9231f29ebf4392992b5c9ce2e385
In the process also move some documentation from the file header to
just above the class declaration.
This change is in response to https://github.com/ceres-solver/ceres-solver/issues/233
Change-Id: I08cff1a94c57b67dd2bd8be4dba8c3fce46b68ab
Support for parameter tolerance was added to the line search
minimizer was added a while ago, and calling Solve on a
non-linear least squares problem supported it but for some reason
the GradientProblemSolver::Options struct was missing this
option even though the documentation suggested that it was present!
Thanks to Noah Snavely for reporting this bug.
Change-Id: I57cf4ab396bc822c19fa298529e113b89664a349
This commit relaxes the tolerance value for comparing between the actual
local matrix and the expected local matrix. Without this fix,
EigenQuaternionParameterization.ZeroTest could fail as the difference
exactly matches the value of std::numeric_limits<double>::epsilon().
Change-Id: Ic4d3f26c0acdf5f16fead80dfdc53df9e7dabbf9
Previously, the test for the projective camera model would fail as no
tolerance is set in line 144. To resolve this, this commit changes
assert_equal to assert_near.
Change-Id: I6cd3379083b1a10c7cd0a9cc83fd6962bb993cc9
Sameer Agarwal