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

[Peter Carbonetto]

Sebastian,

    I sent an email about this earlier:
http://list.coin-or.org/pipermail/coin-ipopt/2007-November/000914.html

    You might try downloading version 3.3.1 of Ipopt; the derivative 
checker seems to work in that release.

    Are there any plans to fix this bug?

Peter Carbonetto
Ph.D. Candidate
Dept. of Computer Science
University of British Columbia

On Mon, 14 Jan 2008, Sebastian Nowozin wrote:

> 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.
>