DynamicNumericDiffCostFunction with initial parameter value near 0. Step is too small.

[albert rasinski]

Hello,
I am a fairly new user of ceres. I have a constrained optimization problem and I am using DynamicNumericDiffCostFunction. Suppose I have a one-dimensional problem with constraint [-2, 2] and a start point equal to 0. In this case, my optimizer does not work because the initial step is too low for my cost function, and could not find any gradient. When I set the initial starting point to 0.0001 my optimizer works perfectly fine. As mentioned in the documentation for ceres::NumericDiffOptions::relative_step_size my initial parameter is close to zero and automatically changes the step size. Changing relative_step_size does not solve my problem. Can I somehow disable the step size change if the parameter is close to zero? Or is there any other solution to my problem?

[albert rasinski]

The first steps are equal to the sqrt(machine_epsilon) as mentioned in the documentation. This is source of my problem.

[Sameer Agarwal]

Albert,

why doesn't the step size of sqrt(machine_epsilon) work for you? are you computing your function in single precision?

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/c1516e6b-ee5a-41d8-a066-a318434f8c93n%40googlegroups.com.

[albert rasinski]

I'm using a maya library that uses eulerian angles / transformation matrices and so on to manage rigs. Looking at the documentation it seems to use double precision, but I'm guessing it loses a lot of precision when converting under the hood. I set up euler rotations to set the rotations of the skeleton. I did a quick test and found that for euler angles less than 3e-8 (radians) the global translation does not change. Theoretically, I may multiply the output of the optimizer but I guess this isn't an elegant solution.

[Sameer Agarwal]

Sorry for the delayed reply, but this seems like that the underlying library is doing something funky or maybe operating in single precision.

I think you will need to figure out how to get approximate derivatives out of this system and then you can feed them into ceres.

The numerical differentiation code that's ships with ceres assumes that the underlying function can be evaluated in double precision and does not resort to lower level precision tricks, thereby junking the derivatives.

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/f54137df-29d1-4f4b-a29d-56d8a8a2e2b3n%40googlegroups.com.