Commit Graph

6 Commits

Author SHA1 Message Date
Keir Mierle 51eb229da3 Add Program::ToString() to aid debugging.
Change-Id: I0ab37ed2fe0947ca87a152919d4e7dc9b56dedc6
2012-08-20 11:46:12 -07:00
Sameer Agarwal 4997cbc437 Return jacobians and gradients to the user.
1. Added CRSMatrix object which will store the initial
   and final jacobians if requested by the user.
2. Conversion routine and test for converting a
   CompressedRowSparseMatrix to CRSMatrix.
3. New Evaluator::Evaluate function to do the actual evaluation.
4. Changes to Program::StateVectorToParmeterBlocks and
   Program::SetParameterBlockStatePtrstoUserStatePtrs so that
   they do not try to set the state of constant parameter blocks.
5. Tests for Evaluator::Evaluate.
6. Minor cleanups in SolverImpl.
7. Minor cpplint cleanups triggered by this CL.

Change-Id: I3ac446484692f943c28f2723b719676f8c83ca3d
2012-07-16 12:17:34 -07:00
Keir Mierle f44907f702 Compute the gradient if requested in the evaluator
This extends the Evaluator interface to support evaluating the
gradient in addition to the residuals and jacobian, if requested.

   bool Evaluate(const double* state,
                 double* cost,
                 double* residuals,
                 double* gradient,  <----------- NEW
                 SparseMatrix* jacobian) = 0;

The ProgramEvaluator is extended to support the new gradient
evaluation. This required some gymnastics around the block
evaluate preparer, which now contains a scratch evaluate preparer
for the case that no jacobian is requested but the gradient is.

Gradient evaluation is a prerequisite for the planned suite of
first order methods, including nonlinear conjugate gradient,
CG_DESCENT, L-BFGS, trust region with line search, and more.

This also considerably refactors the evaluator_test to make it
shorter and check the results for all combinations of the optional
parameters [residuals, gradient, jacobian].

Change-Id: Ic7d0fec028dc5ffebc08ee079ad04eeaf6e02582
2012-07-11 09:44:45 -07:00
Keir Mierle 6196cba4e5 Fix broken constant parameter blocks
This fixes the bug introduced in a previous commit,
and adds a test to check that constant parameter
blocks work as expected.

This also refactors the Solver/SolverImpl split so
that SolverImpl is no longer a friend of Problem;
instead, Solver is. This makes it possible to
verify the invariant on parameter block states in
the unit test, and is a more symmetric design
anyway.

Bug: 51
Change-Id: Id503f5b526cfb8bc24aae3aaad2e414b14063d78
2012-06-19 00:09:53 -07:00
Keir Mierle 57d91f5e9e Don't assume program state is user state
The SolverImpl::Solve() method incorrectly assumed that the
state pointers inside the parameter blocks always pointed to
the user state at the start of the method. That is not true.

Change-Id: I73f8eeda453422c99e09d71a3cd0bfa92dd45742
2012-06-17 23:45:23 -07:00
Keir Mierle 8ebb073038 Initial commit of Ceres Solver. 2012-04-30 23:09:08 -07:00