COBYLA successful termination when constraints violated #2891

Closed
pv opened this Issue Sep 18, 2013 · 9 comments

Projects

None yet

2 participants

Owner
pv commented Sep 18, 2013

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.

Owner
pv commented Sep 18, 2013

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.

Owner
pv commented Sep 20, 2013

PR merged

@pv pv closed this Sep 20, 2013
@ghost
ghost commented Nov 22, 2013

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
Owner
pv commented Nov 23, 2013

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

Owner
pv commented Nov 23, 2013

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

@ghost
ghost commented Nov 24, 2013

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.

Owner
pv commented Nov 24, 2013

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.

Owner
pv commented Nov 24, 2013

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.

@ghost
ghost commented Nov 25, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment