nlopt
nlopt copied to clipboard
stevengj
SLSQP search stopped too early on tutorial constraints
I noticed that the python and C++ tutorials gave different answers when used with SLSQP:
SLSQP was giving the wrong answer on the tutorial in 't_python.py':
optimum at [0.50777849 4.76252907] minimum value = 2.182321944309753
instead of:
optimum at [0.33333333 0.29629629] minimum value = 0.5443310523133087
They are implemented slightly differently, using float multiplication vs ** 2 and ** 3, which result in slightly different floating point values, however that shouldn't cause SLSQP to fail this badly.
The problem isn't with the Python wrapper, because if I reimplement the same function for 'SciPy' it gives the correct answer.
After printing the individual 'f' evaluations I noticed that it stopped the search due to hitting 'xtol_rel', but the function was infeasible at that point (so it returned the last feasible one, which is way off the optimal value). If I instead let the search continue until it finds a feasible point again then it finds the correct answer.
The problem was hinted to at https://github.com/stevengj/nlopt/issues/368#issuecomment-1196810479, which mentions that perhaps feasible_cur should be used, and I think as this example shows that would be the correct approach
(the original SLSQP fortran function also had a check for 'h3', which looks similar to the feasibility check done here).
While fixing the bug I also tweaked the tutorial function to accept the algorithm as parameter and run this during make test to check a few algorithms (those that accept inequality constraints and infinite bounds).
Interesting it fails only on windows but not Linux. I'll take a look, but perhaps for now I'll mark those tests as skipped and fix the problems in another PR (those algorithms were not being tested at all previously I think).
I can reproduce one of the failures on Linux: the starting point is randomly generated and some starting points cause the algorithm to fail with NLOPT_ROUNDOFF_LIMITED.
This will eventually fail: while ./testopt -a 30 -o 1; do echo -n ;done.
I'll remove algorithms 30 and 31 from the tests so far, it looks like their algorithms aren't quite as numerically stable as the other ones.
This will eventually fail:
while ./testopt -a 30 -o 1; do echo -n ;done.
You aren't passing any stopping tolerance to testopt? Probably should be passing e.g. -m 1e-3 so that it stops when it gets close to the (known) minimum.
That being said, the tests should probably also pass -r 0 to use a fixed random seed, in order to lessen the chance of a weird random event biting us on repeated test runs.