COBYLA successful termination when constraints violated

[pv]

The fmin_cobyla algorithm can terminate without actually satisfying the constraints.
Indeed, it has a maxcv return value that reports the constraint violation.

See e.g. http://stackoverflow.com/questions/18782092/python-scipy-optimization-issue-fmin-cobyla-one-constraint-is-not-respected http://pastebin.com/gjbeePgt

This is quite surprising behavior, and definitely not adequately documented.
The COBYLA wrappers probably should check the constraint violation, and return with a failed status if it is bigger than some allowed tolerance.

[pv]

To add insult to injury, in fmin_cobyla the constraint violation is only printed to stdout, and not programmatically accessible. It's accessible in minimize, but not documented.

[pv]

PR merged

[cureos]

I would like to raise some doubt to the validity of this update. Granted, I have not checked the magnitude of the constraint violations, but reading the documentation in the original Fortran 77 file cobyla2.f (available in this package), lines 38 and 39, it is stated:

C1,C2,...,CM denote the constraint functions that should become nonnegative eventually, at least to the precision of RHOEND

If I interpret the scipy API documentation for fmin_cobyla correctly, RHOEND is by default set to 1.0E-4. It would be interesting to know if the observed constraint violations are within this limit.

If the observed constraint violations are less than RHOEND, I would like to argue that this pull request be reverted, and instead recommend fmin_cobyla users that are concerned about constraint violation to incorporate the value of RHOEND in the constraint formulations, i.e.

C[i] + RHOEND >= 0

[pv]

Please check the added example case and the stackoverflow message.
IIRC, the constraint violations were significant.

[pv]

If you decide to it, thanks! One thing less on my kilometer long todo list.

[cureos]

I am not really a python user, I came across this scipy issue since a similar issue had been reported in the C# COBYLA2 repository that I maintain. But looking at the source code provided in the StackOverflow question, I cannot immediately see that the defined c1, c2 and c3 functions correspond to the constraints that they are claimed to represent. It would be more interesting to get an output of the values of the actual constraint functions, rather than the attempted duplication of code in the final three print lines.

[pv]

The constraint violation in the test case added in gh-2893 is 0.35 (the characteristic sizes of constraints c1,c2,c3 are 500,5,5, so the error is larger than rhoend even if it is relative tolerance). Moreover, the error cannot be made smaller by using a smaller rhoend, so I believe your concern is unfounded, and there really is a bug in COBYLA.

[pv]

OTOH, using a smaller rhobeg can make COBYLA to converge to an acceptable solution.
Moreover, given the above, our default value for catol should probably be made to match rhoend.

[cureos]

I have tested the gh-2893 test case myself now running Python 2.7, and yes, I stand corrected. I agree with incorporating this pull request, although I think it might be reasonable to sync the constraint violation analysis with RHOEND instead of introducing a new parameter. But I'll leave this final decision up to you (of course :-) ).

As you also have noted, one solution to avoiding constraint violations in this particular case is to start with a smaller RHOBEG. If you do not mind, I might add that as an answer to the StackOverflow question (with proper credits, of course) to help other SO users.