[Coin-ipopt] Derivative checker problem (IpOpt 3.3.4 over the Matlab interface), ignorance of starting point information
Peter Carbonetto
pcarbo at cs.ubc.ca
Mon Jan 14 15:02:01 EST 2008
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.
>
More information about the Coin-ipopt
mailing list