Roots.jl icon indicating copy to clipboard operation
Roots.jl copied to clipboard

xtol not honored in fzero

Open mzaffalon opened this issue 8 years ago • 5 comments

I cannot seem to be able to set some of fzero's keyword parameters, e.g. xtol and maxeval

julia> f(x) = cos(x) - x
julia> fzero(f, 0; maxeval=20, verbose=true)
Results of univariate zero finding:
<snip>
* iterations: 63
* function evaluations: 65
* stopped as x_n ≈ x_{n-1} using atol=xabstol, rtol=xreltol

julia> fzero(f, 0; xtol=0.2, verbose=true)
Results of univariate zero finding:
* Converged to: 0.7390851332151607
* iterations: 63
* function evaluations: 65

In both cases, there are 65 function evaluations and the root is found to full precision.

The same seems to hold for find_zero.

BTW, what functions are called? There is no line information with @which:

julia> @which find_zero(f, 0; xabstol=0.2, verbose=true)
(::Roots.#kw##find_zero){T<:Number}(::Array{Any,1}, ::Roots.#find_zero, f, x0::T)

mzaffalon avatar Apr 12 '17 06:04 mzaffalon

The furrow function with the default order switches to bisection if possible For Float64, the bisection algorithm ignores xtol. (Though not for big float ). Specifying an order is usually faster, but less robust to initial point.

jverzani avatar Apr 14 '17 06:04 jverzani

Is there a specific reason why xtol is ignored for Float64? I am computing the function by integration and I don't need the full numerical precision.

mzaffalon avatar Apr 26 '17 14:04 mzaffalon

Well, because xtol is usually used as a necessary stopping rule, but in this case of Float64 we can stop when we run out of bits to subdivide. The only method that doesn't respect xtol is bisection over Float64 all others do. However, the default to fzero will use bisection for accuracy when a bracketing interval is stumbled upon so you end up in many cases not having xtol respected. You can specify other algorithms to fzero through its order argument, or you could call the unexported a42 method: Roots.a42(sin, 3.0, 4.0, xtol=1e-3), say.

jverzani avatar Apr 26 '17 15:04 jverzani

If there is no fundamental reason why bisection on Float64 should not respect xtol and if you have no objections, I would like to take a shot at adding it.

In my application, the evaluation of the function is painfully long and I am fine with 3 digits of accuracy. Having to simply specify the pass the tolerance to fzero would be very convenient.

mzaffalon avatar Apr 27 '17 07:04 mzaffalon

I don't have an objection, as long as the default in this case is xtol=0.0 for that stopping rule isn't needed in this case. However, you might just consider passing a different order into the function call. The default is meant to be more robust to the initial condition at the expense of being a bit slower, but many of the orders are reasonable robust to begin with.

On Thu, Apr 27, 2017 at 3:15 AM, Michele Zaffalon [email protected] wrote:

If there is no fundamental reason why bisection on Float64 should not respect xtol and if you have no objections, I would like to take a shot at adding it.

In my application, the evaluation of the function is painfully long and I am fine with 3 digits of accuracy. Having to simply specify the pass the tolerance to fzero would be very convenient.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JuliaMath/Roots.jl/issues/67#issuecomment-297631891, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZvTMDNCDgpHQ2RSUfFlEP8WfLqd18qks5r0ECfgaJpZM4M7Bno .

-- John Verzani Chair, Department of Mathematics College of Staten Island, CUNY [email protected]

jverzani avatar Apr 27 '17 17:04 jverzani