xtol not honored in fzero

[mzaffalon]

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)

[jverzani]

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.

[mzaffalon]

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.

[jverzani]

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.

[mzaffalon]

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.

[jverzani]

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 ***@***.***> 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 <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZvTMDNCDgpHQ2RSUfFlEP8WfLqd18qks5r0ECfgaJpZM4M7Bno> .

-- John Verzani Chair, Department of Mathematics College of Staten Island, CUNY verzani@math.csi.cuny.edu