Complete tests

[Kolaru]

Fix #115

Also suppresses warning from tests that printed them.

This is not finished yet, I open it however to allow discussion on one weird behavior that I would while completing the tests:

bisect use the decoration of the parent interval. This is very reasonnable in general, however it also means that interval bisected from interval(-Inf, Inf) will all have the decroation dac. I belive that this is not what we want here, so I changed it.

Reporting the list from #115

• Add multi dimensional tests to the Out of domain suite.
• Add multi dimensional tests to the Infinite domain suite.
• Add one dimensional tests to the NaN return value suite.
• Use test in test/bisection.jl.
• Adapt tests in test/findroots.jl to the roots suite.
• Add tests in test/newton1d.jl to the tests for the 1D roots suite.
• Test that the examples in the example folder run without error.
• Add some tests from the sources given in docs/test_suites.md.
• Test function with interval parameter (cf. Krawczyk fails for functions with interval parameters #99).
• Add the convoluted double reciprocal case from Reciprocal of reciprocal misses root #131.

[github-actions]

Benchmark Results

	master	3372578...	master / 3372578...
10 dimensional/IntervalRootFinding.Krawczyk	3.5 ± 0.019 s	3.5 ± 0.024 s	0.999 ± 0.0087
10 dimensional/IntervalRootFinding.Newton	53.4 s	52.8 s	1.01
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Krawczyk	4.13 ± 0.16 μs	4.22 ± 0.17 μs	0.979 ± 0.055
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Newton	4.12 ± 0.16 μs	4.19 ± 0.19 μs	0.984 ± 0.059
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Krawczyk	0.123 ± 0.0013 ms	0.124 ± 0.0015 ms	0.988 ± 0.016
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Newton	0.313 ± 0.011 ms	0.315 ± 0.011 ms	0.996 ± 0.05
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Krawczyk	0.364 ± 0.012 ms	0.366 ± 0.012 ms	0.994 ± 0.047
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Newton	0.295 ± 0.012 ms	0.292 ± 0.014 ms	1.01 ± 0.063
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Krawczyk	0.0617 ± 0.00072 ms	0.0625 ± 0.00083 ms	0.987 ± 0.017
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Newton	0.043 ± 0.00065 ms	0.0445 ± 0.00073 ms	0.967 ± 0.022
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Krawczyk	3.95 ± 0.15 μs	4.01 ± 0.16 μs	0.985 ± 0.054
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Newton	3.93 ± 0.14 μs	4.23 ± 2.3 μs	0.929 ± 0.5
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Krawczyk	15.4 ± 0.27 μs	15.6 ± 0.29 μs	0.989 ± 0.025
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Newton	26.3 ± 0.45 μs	26.4 ± 0.51 μs	0.995 ± 0.026
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Krawczyk	4.25 ± 0.19 μs	4.27 ± 0.14 μs	0.995 ± 0.056
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Newton	4.25 ± 0.2 μs	4.28 ± 0.15 μs	0.993 ± 0.058
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Krawczyk	4.55 ± 0.21 μs	4.61 ± 0.15 μs	0.987 ± 0.056
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Newton	4.54 ± 0.2 μs	4.6 ± 0.14 μs	0.987 ± 0.053
Rastigrin stationary points/IntervalRootFinding.Krawczyk	0.158 ± 0.0027 s	0.154 ± 0.0024 s	1.02 ± 0.024
Rastigrin stationary points/IntervalRootFinding.Newton	0.15 ± 0.0018 s	0.148 ± 0.0019 s	1.01 ± 0.018
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Krawczyk	3.26 ± 0.055 ms	3.26 ± 0.067 ms	0.999 ± 0.026
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Newton	2.75 ± 0.05 ms	2.73 ± 0.056 ms	1.01 ± 0.028
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Krawczyk	0.0431 ± 0.0037 s	0.0435 ± 0.004 s	0.991 ± 0.12
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Newton	0.0378 ± 0.0041 s	0.0381 ± 0.0042 s	0.993 ± 0.15
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Krawczyk	2.06 ± 0.041 ms	2.08 ± 0.042 ms	0.991 ± 0.028
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Newton	2.26 ± 0.042 ms	2.22 ± 0.048 ms	1.02 ± 0.029
Smiley/Smiley and Chun (2001), Example 5.5/IntervalRootFinding.Krawczyk	5.49 s	5.69 s	0.965
Smiley/Smiley and Chun (2001), Example 5.5/IntervalRootFinding.Newton	5.19 s	5.24 s	0.991
time_to_load	0.413 ± 0.0083 s	0.404 ± 0.0013 s	1.02 ± 0.021

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

[OlivierHnt]

2 cents thought on the intempestive dac decoration:

The dac decoration tells us that the intervals containing the roots originate from an unbounded domain. Isn’t that actually a feature?
In other words, should we really be striving for com here? A bounded interval carrying the dac decoration unambiguously reflects the "provenance of the computation", no?

The main concern (or worry, so to speak) is that decorations always feel inherently problem-dependent to me. What counts as a 'safe' decoration really depends on the user's context, doesn't it? (in particular, this is why all set operations result in the trv decoration as per the IEEE standard).

If so, following that logic, users should perhaps upgrade the decoration to com themselves afterwards:

interval_with_root = interval(1, 2, dac)
IntervalArithmetic.setdecoration(interval_with_root, com) # [1.0, 2.0]_com

EDIT: Or there could be a special keyword root(...; neglect_dec = (:dac, :def), ...) (in the same vein of what you did for set operations in IntervalArithmetic)?

[Kolaru]

After sleeping on it, I think that I agree, we should just keep the decoration while bisecting, because the interval may come from a previous computation, that got the dac decoration for other reasons.

I'm considering hiding the decoration while displaying the root however, but that should be done in a different PR.

Also, I will open a PR in IA.jl to have Decoration be public, and both decoration and Decoration have clear docstrings stating that decoration dac and com are both in principle totally fine, and that even def is okay in most cases.