Open liuyxpp opened 3 years ago
I think the downside is that it can be harder to debug sometimes and users might also write reltol=1e-5
thinking they're setting a loose tolerance without getting an error that reltol
is not a supported keyword.
However, in src/univariate/solvers/golden_section.jl
, there is a ...nargs
in the optimize
method as follows
function optimize(f, x_lower::T, x_upper::T,
mo::GoldenSection;
rel_tol::T = sqrt(eps(T)),
abs_tol::T = eps(T),
iterations::Integer = 1_000,
store_trace::Bool = false,
show_trace::Bool = false,
callback = nothing,
show_every = 1,
extended_trace::Bool = false,
nargs...) where T <: AbstractFloat
Why is the choice inconsistent?
As you can see, the univariate optimization uses keywords where the multivariate optimization uses an options-type. At some point they probably both had kwargs...
and I forgot to remove it in GoldenSection
. This discrepancy goes back many years, and wouldn't be there if I rewrote it now. I could change it to the options type in v2.0.
At least in
src/univariate/solvers/brent.jl
andsrc/univariate/optimize/interface.jl
(firstoptimize
), theoptimize
function does not capture unsupported kwargs supplied. It makes other packages developed based on Optim much harder to maintain. WhenOptim.optimize
is called in user packages, developers should filter out all unsupported kwargs. Suppose I have a methodNow, if
config.kwargs
contains keyword arguments which are not supported by Optim.optimize, it will not compile. Typical error message isOne possible solution to this is to add an extra
kwargs...
to theoptimize
method inbrent.jl:23
, such asCorrect me if I am wrong or missing some points here.