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	cc84099...	master / cc84099...
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Krawczyk	1.95 ± 0.068 μs	2.02 ± 0.081 μs	0.963 ± 0.051
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Newton	1.95 ± 0.067 μs	2.24 ± 0.097 μs	0.87 ± 0.048
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Krawczyk	0.115 ± 0.00098 ms	0.102 ± 0.00085 ms	1.13 ± 0.014
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Newton	0.301 ± 0.0054 ms	0.251 ± 0.0052 ms	1.2 ± 0.033
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Krawczyk	0.308 ± 0.0062 ms	0.251 ± 0.0062 ms	1.23 ± 0.039
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Newton	0.207 ± 0.0067 ms	0.177 ± 0.0062 ms	1.17 ± 0.056
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Krawczyk	0.06 ± 0.00061 ms	0.0497 ± 0.00058 ms	1.21 ± 0.019
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Newton	0.0377 ± 0.0005 ms	31.6 ± 0.47 μs	1.19 ± 0.024
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Krawczyk	1.75 ± 0.073 μs	1.87 ± 0.1 μs	0.935 ± 0.065
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Newton	1.77 ± 0.057 μs	1.84 ± 0.11 μs	0.958 ± 0.064
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Krawczyk	13.4 ± 0.24 μs	12.1 ± 0.22 μs	1.11 ± 0.028
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Newton	20.8 ± 0.39 μs	18.8 ± 0.33 μs	1.11 ± 0.029
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Krawczyk	2.03 ± 0.078 μs	2.11 ± 0.11 μs	0.962 ± 0.062
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Newton	2.04 ± 0.063 μs	2.09 ± 0.094 μs	0.976 ± 0.053
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Krawczyk	2.27 ± 0.07 μs	2.45 ± 0.11 μs	0.928 ± 0.05
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Newton	2.25 ± 0.061 μs	2.43 ± 0.1 μs	0.926 ± 0.046
Rastigrin stationary points/IntervalRootFinding.Krawczyk	0.155 ± 0.0011 s	0.146 ± 0.001 s	1.06 ± 0.01
Rastigrin stationary points/IntervalRootFinding.Newton	0.148 ± 0.0016 s	0.139 ± 0.00071 s	1.07 ± 0.013
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Krawczyk	4.37 ± 0.065 ms	4.31 ± 0.045 ms	1.01 ± 0.019
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Newton	3.95 ± 0.048 ms	3.93 ± 0.05 ms	1.01 ± 0.018
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Krawczyk	0.0499 ± 0.0038 s	0.05 ± 0.0039 s	0.999 ± 0.11
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Newton	0.0461 ± 0.0035 s	0.0456 ± 0.0038 s	1.01 ± 0.11
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Krawczyk	2.61 ± 0.042 ms	2.61 ± 0.032 ms	1 ± 0.02
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Newton	3.09 ± 0.064 ms	3.07 ± 0.038 ms	1.01 ± 0.024
time_to_load	0.308 ± 0.0024 s	0.305 ± 0.0032 s	1.01 ± 0.013

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...

[Kolaru]

@OlivierHnt I've added support for InconclusiveBooleanOperation.

Also now, instead of having a flag to ignore errors or not, roots take a list of error types and ignores only those specified (default to only InconclusiveBooleanOperation).

What do you think about this design?

[OlivierHnt]

Sounds reasonable that the error is not being thrown but it is still recorded in the output roots.