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	0a454c7...	master / 0a454c7...
10 dimensional/IntervalRootFinding.Krawczyk	3.23 ± 0.019 s	3.27 ± 0.022 s	0.987 ± 0.0088
10 dimensional/IntervalRootFinding.Newton	49.9 s	49.1 s	1.02
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Krawczyk	3.92 ± 0.16 μs	3.96 ± 0.16 μs	0.99 ± 0.057
Dietmar-Ratz/Dietmar-Ratz 1/IntervalRootFinding.Newton	3.9 ± 0.13 μs	3.99 ± 0.17 μs	0.977 ± 0.053
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Krawczyk	0.118 ± 0.0013 ms	0.116 ± 0.0013 ms	1.02 ± 0.016
Dietmar-Ratz/Dietmar-Ratz 2/IntervalRootFinding.Newton	0.302 ± 0.013 ms	0.3 ± 0.013 ms	1 ± 0.061
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Krawczyk	0.356 ± 0.013 ms	0.439 ± 0.015 ms	0.81 ± 0.041
Dietmar-Ratz/Dietmar-Ratz 3/IntervalRootFinding.Newton	0.277 ± 0.013 ms	0.348 ± 0.014 ms	0.796 ± 0.049
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Krawczyk	0.0599 ± 0.00082 ms	0.0595 ± 0.00088 ms	1.01 ± 0.02
Dietmar-Ratz/Dietmar-Ratz 4/IntervalRootFinding.Newton	0.0418 ± 0.0008 ms	0.0414 ± 0.00079 ms	1.01 ± 0.027
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Krawczyk	3.81 ± 0.16 μs	3.77 ± 0.1 μs	1.01 ± 0.05
Dietmar-Ratz/Dietmar-Ratz 5/IntervalRootFinding.Newton	3.77 ± 0.14 μs	3.76 ± 0.1 μs	1 ± 0.046
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Krawczyk	14.9 ± 0.33 μs	14.6 ± 0.26 μs	1.02 ± 0.029
Dietmar-Ratz/Dietmar-Ratz 6/IntervalRootFinding.Newton	25.5 ± 0.56 μs	24.9 ± 0.48 μs	1.03 ± 0.03
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Krawczyk	4.07 ± 0.16 μs	4.05 ± 0.11 μs	1 ± 0.048
Dietmar-Ratz/Dietmar-Ratz 7/IntervalRootFinding.Newton	4.09 ± 0.16 μs	4.05 ± 0.11 μs	1.01 ± 0.048
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Krawczyk	4.37 ± 0.16 μs	4.38 ± 0.14 μs	0.998 ± 0.048
Dietmar-Ratz/Dietmar-Ratz 9/IntervalRootFinding.Newton	4.38 ± 0.16 μs	4.37 ± 0.12 μs	1 ± 0.046
Rastigrin stationary points/IntervalRootFinding.Krawczyk	0.156 ± 0.0013 s	0.158 ± 0.0014 s	0.989 ± 0.012
Rastigrin stationary points/IntervalRootFinding.Newton	0.149 ± 0.0012 s	0.148 ± 0.0018 s	1 ± 0.014
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Krawczyk	3.32 ± 0.054 ms	3.23 ± 0.064 ms	1.03 ± 0.026
Smiley/Smiley and Chun (2001), Example 2.2/IntervalRootFinding.Newton	2.74 ± 0.047 ms	2.64 ± 0.044 ms	1.04 ± 0.025
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Krawczyk	0.0415 ± 0.0034 s	0.0414 ± 0.0036 s	1 ± 0.12
Smiley/Smiley and Chun (2001), Example 5.2/IntervalRootFinding.Newton	0.0362 ± 0.0033 s	0.0356 ± 0.0034 s	1.02 ± 0.13
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Krawczyk	2.21 ± 0.037 ms	2.17 ± 0.044 ms	1.02 ± 0.027
Smiley/Smiley and Chun (2001), Example 5.4/IntervalRootFinding.Newton	2.22 ± 0.034 ms	2.16 ± 0.037 ms	1.03 ± 0.024
Smiley/Smiley and Chun (2001), Example 5.5/IntervalRootFinding.Krawczyk	5.84 s	5.82 s	1
Smiley/Smiley and Chun (2001), Example 5.5/IntervalRootFinding.Newton	5.34 s	5.33 s	1
time_to_load	0.407 ± 0.011 s	0.41 ± 0.0059 s	0.991 ± 0.031

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.