Implement continuing processing on error

[Kolaru]

Fix #232

By default, with this PR, errors are ignored, and the corresponding regions are bisected further, in the hope that by reducing them, the error will go away.

This can be disable by setting the new option bisect_on_error to false.

Whether an error occurred, and why does a root stop being processed are both stored in the Root object, which allows to give more information at the end of the root search.

With this PR, the following works:

using IntervalArithmetic, IntervalRootFinding
using LinearAlgebra
using StaticArrays
using IntervalArithmetic.Symbols

function one_root()
    p(t, p0::AbstractVector, d::AbstractVector) = p0 .+ d .* t

    f(t) = norm(p(t, SVector(-2.0, 0.0, 0.0), SVector(1.0, 0.0, 0.0))) - 1.0

    roots(f, 0.0 .. 10)
end

Resulting in

julia> one_root()
3-element Vector{Root{Interval{Float64}}}:
 Root([1.0, 1.0]_com_NG, :unique)
 Root([2.0, 2.0]_com, :unknown)
    Not converged: region size smaller than the tolerance
    Warning: an error was encountered during computation
 Root([3.0, 3.0]_com_NG, :unique)

Doc and tests are missing and will come soon.

@brianguenter Does it look like a fine solution to your issue?

[github-actions]

Benchmark Results

	master	6fa50a7...	master / 6fa50a7...
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Krawczyk	1.91 ± 0.041 μs	3.65 ± 0.12 μs	0.525 ± 0.021
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Newton	1.97 ± 0.061 μs	3.63 ± 0.13 μs	0.544 ± 0.026
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Krawczyk	0.113 ± 0.001 ms	0.0988 ± 0.00068 ms	1.15 ± 0.013
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Newton	0.268 ± 0.0093 ms	0.237 ± 0.0091 ms	1.13 ± 0.059
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Krawczyk	0.308 ± 0.011 ms	0.33 ± 0.011 ms	0.935 ± 0.046
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Newton	0.205 ± 0.0096 ms	0.234 ± 0.01 ms	0.876 ± 0.056
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Krawczyk	0.0546 ± 0.00071 ms	0.0488 ± 0.00054 ms	1.12 ± 0.019
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Newton	0.0344 ± 0.00058 ms	31.5 ± 0.48 μs	1.09 ± 0.025
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Krawczyk	1.8 ± 0.05 μs	3.54 ± 0.091 μs	0.51 ± 0.019
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Newton	1.82 ± 0.041 μs	3.49 ± 0.11 μs	0.523 ± 0.02
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Krawczyk	12.9 ± 0.16 μs	13.3 ± 0.26 μs	0.969 ± 0.022
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Newton	20 ± 0.28 μs	19.5 ± 0.34 μs	1.03 ± 0.023
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Krawczyk	2.06 ± 0.06 μs	3.8 ± 0.16 μs	0.544 ± 0.028
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Newton	2.07 ± 0.06 μs	3.79 ± 0.15 μs	0.548 ± 0.027
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Krawczyk	2.25 ± 0.05 μs	3.74 ± 0.15 μs	0.603 ± 0.028
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Newton	2.24 ± 0.05 μs	3.7 ± 0.13 μs	0.607 ± 0.026
Rastigrin stationary points/IntervalRootFinding.Krawczyk	0.192 ± 0.0019 s	0.187 ± 0.0016 s	1.03 ± 0.014
Rastigrin stationary points/IntervalRootFinding.Newton	0.181 ± 0.0028 s	0.178 ± 0.0013 s	1.02 ± 0.017
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Krawczyk	4.61 ± 0.055 ms	4.44 ± 0.068 ms	1.04 ± 0.02
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Newton	4.07 ± 0.047 ms	3.85 ± 0.052 ms	1.06 ± 0.019
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Krawczyk	0.0517 ± 0.0031 s	0.0494 ± 0.0031 s	1.05 ± 0.092
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Newton	0.0462 ± 0.0031 s	0.0437 ± 0.003 s	1.06 ± 0.1
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Krawczyk	2.75 ± 0.032 ms	2.65 ± 0.035 ms	1.04 ± 0.018
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Newton	3.13 ± 0.033 ms	3 ± 0.032 ms	1.04 ± 0.016
time_to_load	0.316 ± 0.0021 s	0.315 ± 0.00098 s	1 ± 0.0074

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[brianguenter]

this looks good to me.

[Kolaru]

@OlivierHnt The more I think about it, the more I think only the errors coming from IntervalArithmetic.jl really have a chance to be relevant here. So I would put this on hold, until one of us implement the new error type there. What do you think?

On a side note, there are more changes that necessary, because I also spent some time fixing the doctests while I was at it, even so it is not the core of this PR.

[OlivierHnt]

Sounds good, it's better to properly resolve the issue instead of making a temporary "hotfix".
I can open the PR for the error type in IntervalArithmetic.

[OlivierHnt]

Looks like there is a typo "to" is repeated twice

[OlivierHnt]

I am wondering if the default should be true for bisect_on_error...