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	f26b019...	master / f26b019...
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Krawczyk	1.92 ± 0.041 μs	2.07 ± 0.059 μs	0.928 ± 0.033
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Newton	1.93 ± 0.049 μs	2.1 ± 0.05 μs	0.919 ± 0.032
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Krawczyk	0.116 ± 0.0012 ms	0.0999 ± 0.00089 ms	1.16 ± 0.015
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Newton	0.275 ± 0.011 ms	0.233 ± 0.01 ms	1.18 ± 0.07
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Krawczyk	0.307 ± 0.012 ms	0.33 ± 0.011 ms	0.931 ± 0.048
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Newton	0.208 ± 0.011 ms	0.243 ± 0.011 ms	0.855 ± 0.058
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Krawczyk	0.0582 ± 0.00076 ms	0.0482 ± 0.00051 ms	1.21 ± 0.02
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Newton	0.0378 ± 0.00066 ms	31 ± 0.46 μs	1.22 ± 0.028
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Krawczyk	1.82 ± 0.053 μs	2.06 ± 0.04 μs	0.884 ± 0.031
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Newton	1.77 ± 0.06 μs	2.3 ± 0.041 μs	0.77 ± 0.029
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Krawczyk	13 ± 0.18 μs	11.6 ± 0.13 μs	1.12 ± 0.02
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Newton	20.2 ± 0.31 μs	18.2 ± 0.24 μs	1.11 ± 0.022
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Krawczyk	1.98 ± 0.06 μs	2.15 ± 0.05 μs	0.921 ± 0.035
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Newton	1.99 ± 0.05 μs	2.17 ± 0.05 μs	0.917 ± 0.031
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Krawczyk	2.3 ± 0.06 μs	2.49 ± 0.041 μs	0.924 ± 0.028
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Newton	2.3 ± 0.051 μs	2.5 ± 0.05 μs	0.92 ± 0.027
Rastigrin stationary points/IntervalRootFinding.Krawczyk	0.151 ± 0.00092 s	0.149 ± 0.0013 s	1.01 ± 0.011
Rastigrin stationary points/IntervalRootFinding.Newton	0.145 ± 0.0014 s	0.142 ± 0.0012 s	1.02 ± 0.013
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Krawczyk	4.41 ± 0.049 ms	4.51 ± 0.068 ms	0.978 ± 0.018
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Newton	3.89 ± 0.047 ms	3.88 ± 0.044 ms	1 ± 0.016
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Krawczyk	0.0518 ± 0.0033 s	0.0509 ± 0.0028 s	1.02 ± 0.086
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Newton	0.0445 ± 0.003 s	0.0446 ± 0.0028 s	0.998 ± 0.092
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Krawczyk	2.65 ± 0.033 ms	2.71 ± 0.034 ms	0.976 ± 0.017
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Newton	3 ± 0.03 ms	3.07 ± 0.043 ms	0.98 ± 0.017
time_to_load	0.315 ± 0.0036 s	0.316 ± 0.00096 s	0.998 ± 0.012

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.