[SciPy-Dev] An inconsistency in scipy.optimize.minimize

[Yuxiang Wang]

Dear all,

Please ignore my last email - I got "epsilon" and "eps" reversed in my mind.

I am really sorry for the spam.

-Shawn

On Fri, Feb 21, 2014 at 8:25 AM, Yuxiang Wang <yw5aj at virginia.edu> wrote:
> Thank you Pauli for your response! And sorry for replying late.
>
> I agree with you that we should not use fmin_* functions in the
> future, and neither should we break backward compatibility. However I
> do see a problem the overall consistency and the document. Could we
> make both "epsilon" and "eps" work? Let me try to explain here.
>
> All functions except minimize uses "eps" and have it documented;
> minimize with all other algorithms (e.g., "bfgs") uses "eps"; only
> minimize uses "epsilon" when "l_bfgs_b" is called, which is
> inconsistent, and what's worse... it is nowhere documented. There is
> nowhere in the minimize document saying that I should use the
> parameter "epsilon" for "l-bfgs-b". The only hint I could get is in
> fmin_l_bfgs_b, and it says "eps", not "epsilon".
>
>
>
> I use show_options and it still wouldn't tell me to use "epsilon".
> This is what I got:
>
> In [6]: from scipy.optimize import minimize, show_options
> In [7]: show_options('minimize', 'BFGS')
>
> BFGS options:
> gtol : float
> Gradient norm must be less than `gtol` before successful
> termination.
> norm : float
> Order of norm (Inf is max, -Inf is min).
> eps : float or ndarray
> If `jac` is approximated, use this value for the step size.
>
> In [8]: show_options('minimize', 'L-BFGS-B')
>
> L-BFGS-B options:
> ftol : float
> The iteration stops when ``(f^k -
> f^{k+1})/max{|f^k|,|f^{k+1}|,1} <= ftol``.
> gtol : float
> The iteration will stop when ``max{|proj g_i | i = 1, ..., n}
> <= gtol`` where ``pg_i`` is the i-th component of the
> projected gradient.
> maxcor : int
> The maximum number of variable metric corrections used to
> define the limited memory matrix. (The limited memory BFGS
> method does not store the full hessian but uses this many terms
> in an approximation to it.)
> maxiter : int
> Maximum number of function evaluations.
>
> None of them made me realize the name "epsilon" is usable - the only
> hint is that I might try "eps", but it didn't work.
>
> -Shawn
>
> On Sun, Feb 16, 2014 at 7:59 AM, Pauli Virtanen <pav at iki.fi> wrote:
>> Hi,
>>
>> 16.02.2014 06:22, Yuxiang Wang kirjoitti:
>>> Sorry about digging this out again... As well as not knowing how to
>>> contribute my effort to SciPy. Sorry about being ignorant in how to
>>> participate in an open-source project, but what is the suggested step
>>> that I should do next? Should I:
>>>
>>> 1) Report this issue on github
>>>
>>> 2) Fix the code
>>>
>>> I could do both, but the code would be only on my personal machine and
>>> not thoroughly tested... Could anyone please help and get me started
>>> on that?
>>>
>>> Thanks so much!
>>>
>>> -Shawn
>>>
>>> On Mon, Jan 27, 2014 at 4:55 PM, Yuxiang Wang <yw5aj at virginia.edu> wrote:
>>>> Aaron,
>>>>
>>>> Thanks for confirming! I agree that epsilon is better, as in the
>>>> following functions "epsilon" instead of "eps" are used:
>>>>
>>>> scipy.optimize.fmin_cg
>>>> scipy.optimize.fmin_ncg
>>>> scipy.optimize.fmin_tnc
>>>> scipy.optimize.fmin_bfgs
>>>> scipy.optimize.fmin_l_bfgs_b
>>
>> The overall situation is that `fmin_*` exist only for backward
>> compatibility, and may be deprecated at some point if this seems
>> sensible. Everything that they can do, also minimize() can do.
>>
>> minimize() was introduced to provide a standard interface with
>> consistent parameter names, since the fmin_* were inconsistent between
>> each other.
>>
>> It does not seem wise to me for us to start changing the parameter names
>> in minimize() again, just for aesthetic reasons.  This will break
>> backward compatibility, and moreover, users of minimize() should not
>> need to use the fmin_* functions.
>>
>> --
>> Pauli Virtanen
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Yuxiang "Shawn" Wang
> Gerling Research Lab
> University of Virginia
> yw5aj at virginia.edu
> +1 (434) 284-0836
> https://sites.google.com/a/virginia.edu/yw5aj/



-- 
Yuxiang "Shawn" Wang
Gerling Research Lab
University of Virginia
yw5aj at virginia.edu
+1 (434) 284-0836
https://sites.google.com/a/virginia.edu/yw5aj/