When using the SPARSE_QR algorithm, now a Q-less
factorization is used. This results in significantly
less memory usage.
The inversion of the semi-normal equations is now
threaded using openmp. Indeed if one has SuiteSparse
compiled with TBB, then both the factorization
and the inversion are completely threaded.
Change-Id: Ia07591e48e7958d427ef91ff9e67662f6e982c21
Main purpose of this is to make implementation files free from
endless ifdef blocks every time this libraries are needed to be
included. This would hopefully prevent compilation errors in
the future caused by missing ifdef around header include.
This also includes some stubs added to suitesparse/cxsparse
headers to make code even more free from ifdefs.
Change-Id: Ic8554e7df31d8c4751583fe004b99e71b3c9087b
1. When a LAPACK implementation is present, then
DENSE_QR, DENSE_NORMAL_CHOLESKY and DENSE_SCHUR
can use it for doing dense linear algebra operations.
2. The user can switch dense linear algebra libraries
by setting Solver::Options::dense_linear_algebra_library_type.
3. Solver::Options::sparse_linear_algebra_library is now
Solver::Options::sparse_linear_algebra_library_type to be consistent
with all the other enums in Solver::Options.
4. Updated documentation as well as Solver::Summary::FullReport
to reflect these changes.
Change-Id: I5ab930bc15e90906b648bc399b551e6bd5d6498f
colPivHouseholderQR -> householderQR
ldlt -> llt.
The resulting performance differences are significant enough
to justify switching.
LAPACK's dgels routine used for solving linear least squares
problems does not use pivoting either.
Similarly, we are not actually using the fact that the matrix
being factorized can be indefinite when using LDLT factorization, so
its not clear that the performance hit is worth it.
These two changes result in Eigen being able to use blocking
algorithms, which for Cholesky factorization, brings the performance
closer to hardware optimized LAPACK. Similarly for dense QR
factorization, on intel there is a 2x speedup.
Change-Id: I4459ee0fc8eb87d58e2b299dfaa9e656d539dc5e
Covariance implementation file used to unconditionally include
SuiteSparseQR.hpp which caused compilation error in cases you
don't have SuiteSuite installed to the system
Moved the include to #ifdef block.
Change-Id: I3a52c0f81711b2b70ae625fe80b758ecb0817cc6
-fast compiler option is only supported using Apple's GCC packaged with XCode.
Other GCC versions will fail when this flag is enabled. This commit checks the
GCC version on OSX and only enables this flag when < 4.3. Apple's GCC is
currently 4.2.1 and a user is unlikely to install a non-apple version this old
on OSX.
Change-Id: Ifca9149625c065cd16559d7e30c218a322cf79aa
SuiteSparse_long is only defined in recent versions of SuiteSparse
as the index variable type for large matrices. In older versions
UF_long was used. Ubuntu still ships with an older version of
SuiteSparse, so an ifdef is needed to fix the build.
This patch has been tested on mac and on linux with older and
newer versions of SuiteSparse.
Change-Id: I4ada86d7973784a79bde4afec13ce3ca4e8dc225
1. Typo in c_api.h
2. The stream operator for FunctionSample is now in the ceres::internal namespace.
Change-Id: Id927a7a49c47d8903505535749ecca78cd2e83b3
OpenBLAS has subtle issues releated to threading. It
conflicts with the use of threads in the other parts of
the application.
Careful users can still use it by disabling threads via
an environment variable, but by default we want to use
a BLAS/LAPACK that does not suffer from these problems.
Change-Id: I8c1c0ed0b526453564c5f9ea69b646fac32fe027
Reduce the verbosity of the Cmake file. All the "Checking for"
messages have been removed since we log both success and failures.
Further, UFConfig is only searched for if SuiteSparse_config cannot
be found.
Change-Id: I601a6ffc808e566ff78ce232c86519ef413f0b33
This extends the C API to support loss functions. Both
user-supplied cost functions as well as the stock Ceres cost
functions (Cauchy, Huber, etc) are supported. In addition, this
adds a simple unit test for the C API.
Supporting loss functions required changing the signature of the
ceres_add_residual_block() function to also take a thunk for the
loss function.
Change-Id: Iefa58cf709adbb8f24588e5eb6aed9aef46b6d73
lm_max_diagonal -> max_lm_diagonal
lm_min_diagonal -> min_lm_diagonal
linear_solver_max_num_iterations -> max_linear_solver_iterations
linear_solver_min_num_iterations -> min_linear_solver_iterations
This follows the pattern for the other parameters in Solver::Options
where, the max/min is the first word followed by the name of the
parameter.
Change-Id: I0893610fceb6b7983fdb458a65522ba7079596a7
Previously there was an assignment dimension mismatch in the
history update; thus, over time, the history would contain
(only) replicated copies of the (max_num_corrections_ -1)-th
update and the most recent update.
Change-Id: I26203acf689686d41a5029c675ebbe001fe05d90
1. When protocol buffers support is enabled CompressedRowSparseMatrix
has a missing virtual method.
2. When SuiteSparse is missing, covariance_test tries to run the
large scale covariance computation test.
Thanks to Alex Stewart for reporting #1.
Change-Id: I4238c966036362175e31749595ea8bb6f12a696c
Drop support for protocol buffers.
Add CompressedRowSparseMatrix::CreateBlockDiagonalMatrix.
Add CompressedRowSparseMatrix::SolveLowerTriangularInPlace.
Add CompressedRowSparseMatrix::SolveLowerTriangularTranposeInPlace.
Add CompressedRowSparseMatrix::Transpose.
Change-Id: I2328afca9fac632685eac72ebb00998bd3510187
Issue was caused by the way how SUITESPARSE_FOUND was set and
used in IF conditions later. Basically, SUITESPARSE_FOUND was
setting to a value which needed to be expanded using ${} to get
it's actual value.
Made it so SUITESPARSE_FOUND is setting to either TRUE or FALSE
from an IF condition which does check for whether all the
dependencies are met.
Also removed expanding some of the variables in IF conditions,
they're not needed actually.
Change-Id: Iad01a3a49fb500375e344e5352a56a0c89be3b5a
fix compilation error on Ubuntu 12.0
In file included from /usr/include/fcntl.h:252:0,
from /home/ajg23/src/ceres-solver/examples/libmv_bundle_adjuster.cc:91:
/home/ajg23/src/ceres-solver/examples/libmv_bundle_adjuster.cc: In member function ‘T {anonymous}::EndianAwareFileReader::Read() const [with T = unsigned char]’:
/home/ajg23/src/ceres-solver/examples/libmv_bundle_adjuster.cc:300:5: error: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Werror=unused-result]
Change-Id: Ib23ca19778761bbfe0d77bcf32a2181ce6db1a12
Issue was caused by declaring class PerThreadContext with some
members of choldmod-specific types. This class in only used from
an #ifndef CERES_NO_SUITESPARSE block and solved compilation error
by simply wrapping PerThreadContext with the same #ifndef block.
Change-Id: Icdc329073fcbd4a328e41ea8c0af0962e9c34ba8
Changed DynamicAutoDiffCostFunction to handle multiple derivative
sections as opposed to just a single contiguous block.
In the previous implementation it was assumed that non-constant
parameters occur in a single contiguous block so that constant
parameters could NOT lie between non-constant parameters. Previously,
start_derivative_section was first set as soon as the first
non-constant parameter block (marked by jacobians[i] != NULL) was
encountered. After this, entries in input_jets[parameter_cursor].v were
accessed with `parameter_cursor - start_derivative_section`. For
contiguous non-constant parameter blocks this is fine, but if constant
parameter blocks fall between then this indexing is incorrect because
`parameter_cursor - start_derivative_section` can go out of bounds.
For a concrete example, take a cost function with three parameter
blocks, each of size 1 and with the center block fixed. Assume that
Stride=1 so that two passes are required. On the first pass
start_derivative_section=0, and the first variable block is handled
correctly. At the end of the first pass end_derivative_section=1, so
for the second pass start_derivative_section=1. Now comes the problem.
When parameter_cursor=1, parameter_cursor >= start_derivative_section
so jacobian[1] is checked to be NULL. Since it is NULL (second
parameter block is constant) then nothing is done and
active_parameter_count is NOT incremented. Next, when
parameter_cursor=2, parameter_cursor >= start_derivative_section and
jacobian[2] is checked. Since it is not NULL then
input_jets[parameter_cursor].v[parameter_cursor -
start_derivative_section] is set to 1.0, BUT parameter_cursor -
start_derivative_section = 2 - 1 = 1 which is out of bounds
(input_jets[parameter_cursor].v is only of size Stride=1).
The proposed solution records the start of each contiguous block of
non-constant parameters and indexing into
input_jets[parameter_cursor].v is independent of parameter_cursor.
Change-Id: I388ab6a0bafa35d317491135ec6fe980453ff888
Ordering of Problem::RemoveParameterBlock and Problem::RemoveResidualBlock
changed, as RemoveResidualBlock is being referred in RemoveParameterBlock
with "above".
Change-Id: I07f8e7b7e20ba239a72c15ed9e79576f5def090a
Not entirely sure how and why this was compiling up till now.
Thanks to Carlos Hernandez for reporting this.
Change-Id: Ieadbb8cb0a3769afe9dcef927ff0287342e44f1f
This sets the stage of preconditioners that can utilize
different kinds of matrix layouts, just like the LinearSolver
class hierarchy.
Change-Id: I3579cf344bcd2eeeecb1ae621cab02a3c9a0f920
This support was broken due to the TrustRegionMinimizer refactoring.
It is now enabled again, with the responsibilty for dumping the
problem shifted to the individual TrustRegionStrategy.
There is however one wrinkle, which is perhaps an indication of
poor design to start with. The LinearLeastSquaresProblemProto
carries in it num_eliminate_blocks, something which does not
exist anymore. More importantly, the TrustRegionStrategy does not
have access to this quantity anymore.
Dealing with this will be the subject of a future change.
Change-Id: I358adf6a2e386f4940b617bf950d6c7e87d2635d
CreateJacobianBlockSparsityTranspose starts with a conservative
estimate of the size of the block sparsity pattern of the Jacobian.
When the Jacobian has more non-zeros than that, the TripletSparseMatrix
being used to store the sparsity has a Reallocate method which
allows one to resize the matrix and IF num_nonzeros is set, then the
existing values in the array are also copied into the newly allocated
memory.
Unfortunately the pattern we follow in ceres code is to call
set_num_nonzeros after one is done populating the sparsity pattern
of a matrix. This does not mix well with Reallocate and results
in the matrix having uninitialized memory.
This patch fixes this problem and adds a test that verifies the fix.
Thanks to Yuliy Schwartzburg for reporting this bug and providing
code to reproduce it.
Change-Id: I58583714ffaebd880d85af16e3685b2d6ee053e8
Sameer Agarwal