commit 32cb9e4a12f19a10c6987e6f9769030f0f2c824c
author Sameer Agarwal <sameeragarwal@google.com> Sat Jul 07 17:11:38 2018 -0700
committer Sameer Agarwal <sameeragarwal@google.com> Mon Jul 09 23:48:45 2018 -0700
tree b94ab487606ee5a9d3a5794a143b770d151c3088
parent 2dd82fb8a010227bdb534853f4d37f43e1031df0

Respect bounds when using Solver::Options::check_gradients

When Solver::Options::check_gradients is true, Ceres internally
creates a new ProblemImpl object which wraps each CostFunction
in the user's problem with a GradientCheckingCostFunction.

Doing this also requires creating new ParameterBlock objects,
and when support for upper and lower bounds was added to Ceres,
CreateGradientCheckingProblemImpl should also have been updated
to create a problem with the same parameter bounds. As a result,
if check_gradients is enabled for a bounded problem, it constructs
an unconstrained problem and solves it.

This CL fixes this, by introducing Problem::GetParameterLowerBound,
and Problem::GetParameterUpperBound and using them to create a bounded
problem when checking gradients.

Thanks to @pbeeson for not only reporting this problem, but also
providing a small standalone reproduction which made debugging this
possible.

https://github.com/ceres-solver/ceres-solver/issues/379

Change-Id: Id18eb858a7009bf4fa452a21b925922d13f3249f