[Coin-ipopt] Derivative checker problem (IpOpt 3.3.4 over the Matlab interface), ignorance of starting point information

[Sebastian Nowozin]

Hello,

it seems my previous mail was a little bit too fast.  Infact I believe
there is a bug in either the Matlab interface or IpOpt derivative
checker.
I verified all my derivatives manually and by running
finite-difference checks myself.

The objective contains a sum of log(x) terms and I initialize x=1 for
all these variables.  The derivative checker documentation and code
says the check is performed around the initial starting point.
However, both the actual derivative value, as well as the
finite-difference approximation are very large.  I pinpointed the
problem: the check is not performed around the given starting point,
but around zero, x is tested at 1.0213e-08 and 2.1324e-10 instead of 1
and 1 + 1e-8.

This produces "errors" in the derivative check then, as a gradient of
the logarithm at 2.1324e-10 is obviously difficult to approximate by
finite differences.

Starting derivative checker.

* grad_f[          0] = -1.1723767071873160e+08    ~
-9.6725313515225500e+06  [ 1.112e+01]
* grad_f[          1] = -1.0738670595914723e+07    ~
-4.1671285135755907e+06  [ 1.577e+00]
* grad_f[          2] = -5.8463631871292852e+06    ~
-3.0138379141483540e+06  [ 9.398e-01]
* grad_f[          3] = -1.4526332092329852e+07    ~
-4.7961759010235025e+06  [ 2.029e+00]
* grad_f[          4] = -8.6308330828022584e+06    ~
-3.7335707020481834e+06  [ 1.312e+00]
* grad_f[          5] = -2.7622448487412033e+09    ~
-1.7521032247221056e+07  [ 1.567e+02]
* grad_f[          6] = -2.6017683345673114e+07    ~
-6.0855840781478323e+06  [ 3.275e+00]
* grad_f[          7] = -4.9277834346935088e+06    ~
-2.7223418898174143e+06  [ 8.101e-01]
...
*             obj_hess[    0,    0] =  5.4978685742214944e+17 v  ~
1.1478986815970806e+16  [ 4.690e+01]
*             obj_hess[    1,    1] =  4.6127618467025390e+15 v  ~
8.7107723794524650e+14  [ 4.295e+00]
*             obj_hess[    2,    2] =  1.3671985006328195e+15 v  ~
4.0951923310177231e+14  [ 2.339e+00]
*             obj_hess[    3,    3] =  8.4405729622660870e+15 v  ~
1.2393410566196550e+15  [ 5.811e+00]
*             obj_hess[    4,    4] =  2.9796511881277575e+15 v  ~
6.6923364270269225e+14  [ 3.452e+00]
*             obj_hess[    5,    5] =  3.0519986417589256e+20 v  ~
2.7597471093476394e+17  [ 1.105e+03]
*             obj_hess[    6,    6] =  2.7076793867028640e+16 v  ~
2.3736845608057525e+15  [ 1.041e+01]
*             obj_hess[    7,    7] =  9.7132198316959000e+14 v  ~
3.2692188447254775e+14  [ 1.971e+00]


I fear that also the optimization starts at this numerically difficult
points, using the "exact" Hessian.  Can someone confirm this bug?

Sebastian

PS: I also send it to Peter Carbonetto, the author of the (excellent)
Matlab interface.