nlopt
nlopt copied to clipboard
stevengj
Back away from inequality constraints that evaluate to NaN
This permits slsqp to deal with the interaction between inequality constraints and soft feasibility constraints.
Actually these changes are good. The problem I was having was caused by use of ftol instead of xtol on a constrained problem.
Hm, do I need to save/restore slsqpb_state if I pick a point from the line search that is not the last point?
@jpritikin, regarding the SAVE/RESTORE_STATE: if I remember correctly, the original Fortran code was using the equivalent of static C local variables for these things, and I wanted it to be re-entrant & thread-safe. So, the state only needs saving inside the slsqpb_, and should be saved at every exit point from that function (unless you will never come back, e.g. you are exiting because you have converged or there was an error).
Could you squash these (via git rebase --interactive followed by a git push -f) into a single commit? Also be sure to put (for #30) in the commit message so that #30 will be cross-referenced.
regarding the SAVE/RESTORE_STATE
This question was addressed with https://github.com/jpritikin/nlopt/commit/356bd27e08bbd20abb07534b6678257492ec8421
Should the s[i__] = x[i__] - x0[i__]; loop be executed every time we goto L260, or only from the beginning of the slsqpb_ function? Maybe you should move it before the relevant goto.
Should the s[i__] = x[i__] - x0[i__]; loop be executed every time we goto L260, or only from the beginning of the slsqpb_ function?
Sorry, I can't remember. Certainly the code doesn't hurt. It helps preserve an invariant condition that should be preserved.