Boundary interpolation bug

[Elektrostraka]

When a Ceres solver starts with a point just on a boundary (min or max limit), the Ceres does not do optimization steps and locks itself on the boundary point. The same happens randomly when Ceres gets to any boundary (min or max limit) during optimization steps - it stops optimization step on the boundary.

The error is obviously in the interpolation calculation due to numeric error, which numerically appears to start from a point little behind the boundary limit. This happens when a programmer forgets to check the optimization step goal validity before iteration calculation.

Proposed correction: The code must check the optimization step direction first, then compare whether the direction goes out of boundary or inside of boundaries. Inside of boundaries is valid, outside of boundaries is invalid. For a valid iteration goal, the interpolation must not be done, while the goal is valid completely. For an invalid iteration goal only, the interpolation has to be done.

I have discovered this bug on a version 2.1.0. Since I have not found any such bug in issues list descriptions nor in a bug fixes list of a new version 2.2.0, I have input this issue here, while this bug probably still persists in new version also.

[sandwichmaker]

Sorry for taking so long to reply to this, do you have a simple reproduction of this?

[Elektrostraka]

Unfortunately I am not able to create a simple reproduction of this bug, while the project which uses this library is very complex (it' s ROS project). I can just supply some part of information:
there is a numeric 1-dimensional cost functor,
3 variables optimized,
each of 3 variables has its own minimum and maximum boundary.
Problem happens whenever optimization algorithm reaches any boundary during optimization process, including starting point exactly on a boundary limit,
ceres::LinearSolverType::DENSE_QR

Is some more information necessary?