[SciPy-User] Flaws in fmin_cobyla
Thu Sep 27 04:26:14 CDT 2012
Robaula a écrit :
>>> 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
> Sorry, the documentation is flat wrong. Both disp and iprint are
> completely, utterly, and totally ignored. See fmin_cobyla line 165.
disp and iprint parameters are not ignored, they are passed from
fmin_cobyla to _minimize_cobyla through the opts dictionary.
- with disp != 0, fmin_cobyla prints things whatever the value of
iprint, because iprint=disp;
- with disp unspecified or None and iprint !=0, you get the same behaviour.
- minimize just considers Boolean values of disp and switch between
iprint=0 or iprint=1, as do most other methods.
So what's wrong? Am I missing something?
> Then I guess we'd have to deprecate nearly all of the optimize and
> root-finding stuff mentioned in the SciPy Reference Guide on pages
> 388-442?? I note that Ralf Gomers thinks we should find a better way.
> Cleaning up the fmin_cobyla documentation can certainly be a start on
> that, and I'll take that on.
> However, I think there other, and more important issues here,
> namely, "How should the new 'minimize' interfaces be documented? How
> should existing documentation for the "old" interfaces be changed in
> light of the new 'minimize' approach? How to bring the two of them
> more nearly into alignment? Are changes to the documentation
> standards advisable to facilitate this?"
If fmin_ functions ain't be deprecated, maybe these should at least not
appear in the reference guide at the same level as minimize and root
interfaces. The current situation is clearly confusing IMO.
> Sure, "minimize's" docstring is an excellent start, tho I do see a
> couple areas where a little more explanation and/or some examples
> would be helpful. Among other things, I think it would be a lot
> better to just come out and tell folks what options are available for
> each of the various "methods", rather than telling them the code
> sequence to use to view them.
This particular point was discussed during implementation of the
interface, and there was an agreement that the docstring should not be
filled with options specific to each method, hence the advice to refer
to show_minimize() for the latter. There's probably room for
> Certainly the cobyla options for 'minimize' differ noticeably from
> those for the fmin_cobyla approach.
The idea was to streamline the options amongst solvers.
> I'm looking for documentation suitable for use by folks who might be
> described as: first year grad students just slightly familiar with
> Python who have a one week deadline to solve their problem and
> desperately need _very_ clear, unambiguous, and detailed instructions
> on exactly how to proceed. Try to remember _your_ first year grad
This is what the optimize tutorial  is for, I guess.
More information about the SciPy-User