[SciPy-User] Flaws in the cobyla routine

[Denis Laxalde]

Robaula a écrit :
> 1. The routine returns only the optimal argument value. No description of the status at the end of the run, such as would be provided by the "Results" class are included. Consequently the user receives no information on the trustworthiness of the returned value.

You mean `fmin_cobyla`, I guess. See answer to point 4.

> 2. Although "disp" and "iprint" are among the options in cobyla's calling signature, assigning different values to them has absolutely no effect on the output.

This is documented. `disp` overrides `iprint`, which is deprecated.

> 3. The docstring's Examples section mentions several values that would be included in the "Results", but with no indication of where they come from or how the users could get at them.

Which docstring?
Most of the information comes from the internal solver.
As mentioned in its docstring, `Result` is a subclass of `dict` with 
attribute accessors. You may then access attributes with a dot notation 
or as a regular dict.

> 4. The cobyla routine calls the _minimize_cobyla routine, which prepares and returns the "Results" class information. This includes: the optimal value of the argument, the status at end, the success flag value, a message expressing the success flag in English, the optimal value of the function, and the maximum constraint violation. Then the cobyla routine "throws away" all but the first of these values. That occurs because after the cobyla routine receives the "Results" dictionary of values from _minimize_cobyla, it returns, in effect, "Results['x']", i.e., just the "Results" dictionary entry for key 'x'.  This is done in line 165 of the cobyla routine.

The `Result` object was introduced recently, for the `minimize` 
interface. It is not returned by `fmin_cobyla` for backwards 
compatibility. If you want the full results, use `minimize(..., 
method='cobyla', ...)`.

The old `fmin_` functions and the new `minimize` interface are present 
in the 0.11 release, which is good for transition purpose but is also 
confusing. We could deprecated the former in the next release I guess.

> In addition to reporting the maximum constraint violation, it would be helpful to also report which constraint(s) caused the maximum constraint violation. It would also be useful to report which constraints were "tight" and which were "loose."

You may fill a bug report (enhancement) for this, or better, a pull request.

-- 
Denis Laxalde