Unexpected library error message when finding roots of simple function

[brianguenter]

I was testing interval root finding to see if it would work for my application and created this simple problem:

using IntervalArithmetic, IntervalRootFinding
using LinearAlgebra: norm
using StaticArrays: SVector
using IntervalArithmetic.Symbols
using Plots

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

    plot(f, 0.0:0.01:4.0)
    roots(f, 0.0 .. 10)
end

When I run one_root I get this error:

ERROR: ArgumentError: < is purposely not supported for overlapping intervals. See instead strictprecedes

f(t) is not that weird a function. It has a zero at 1 and at 3:

Am I misusing the IntervalRootFinding library? Or is this a bug?

[Kolaru]

Thanks for reporting, this is indeed a bug!

The core issue is that StaticArrays use comparisons in their definition of the norm, which is not in general a valid operation on intervals.

However, it has deeper consequences, and it is quite timely that it got reported before I get around releasing v1.0 :)

We can make IntervalRootFinding consider intervals that errors to be of :unkown status (by catching the error), so that it would get bisected until we reach region on which the < operation is valid. This would solve the issue here entirely, but will also require a bit of thinking in order to make sure that relevant error information still reach the user and allow them to debug their own code.

One thing that could help would be to define our own error type in IntervalArithmetic (e.g. InconclusiveBooleanOperation) for this kind of errors, and limit ourselves to them for now. What do you think about that @OlivierHnt ?

Alternatively, we could catch all errors and either add the caught errors to the root object themselves, or return a solution object (in the style of DifferentialEquations) which would contain them all.

In addition to dealing with errors in general (which I think should be done), we can also remove this specific one with a StaticArrays extension in IntervalArithmetic.

[OlivierHnt]

Making an error type InconclusiveBooleanOperation <: Exception is a great idea; we also need to make a package extension in IntervalArithmetic for StaticArrays. I'll make a PR in the coming days.

1. I personally do not have preferences about using the :unknown status to report InconclusiveBooleanOperation; if the definition of :unknown is that something went wrong (in a broad way) and nothing can be said about the interval, then that might be a clever trick to avoid an InconclusiveBooleanOperation error.

2. I actually do not know how DifferentialEquations deals with error handling. They probably had quite some experience on this, and their approach could be insightful if it applies here.

Implementing 1. above seems the simplest and fastest; if implementing 2. is not breaking, then this can always be done after the 1.0 release.

@brianguenter so a quick fix for now would be to not use StaticArrays.