Define `AbstractContractor` here and import it in other packages

[lucaferranti]

At the moment both IntervalRootFinding and ICP define a type Contractor in incompatible ways (Contractor is an abstract type in IntervalRootFinding and a concrete type in ICP). This produces some unpleasant complications if both packages are imported.

julia> using IntervalRootFinding, IntervalConstraintProgramming, ModelingToolkit

julia> @variables x y
(x, y)

julia> C = Contractor(x+y)
WARNING: both IntervalConstraintProgramming and IntervalRootFinding export "Contractor"; uses of it in module Main must be qualified
ERROR: UndefVarError: Contractor not defined
Stacktrace:
 [1] top-level scope at REPL[23]:1

Maybe we could define AbstractContractor as an abstract type in this package and have

• Newtonn, Krawczyk, Bisection <: AbstractContractor in IntervalRootFinding
• Contractor, BasicContractor <: AbstractContractor in ICP

with AbstractContractor being imported from here in both packages.

I guess a more coherent name for the current Contractor in ICP would then be ForwardBackward, but maybe it is a little clumsy as a name?

Anyway, here just a couple of ideas to start brainstorming.

[Kolaru]

Are contractors from IntervalRootFinding and from ICP of the same kind? As far as I understand they aren't and so should not share the same abstract type.

To solve the problem Contractor could be renamed to ContractionOperator in IntervalRootFinding, since its subtypes are referred to as operators (i.e. Newton and Krawczyck operators).

[dpsanders]

Yes, they are actually the same, conceptually speaking: they take in a box and return a hopefully-smaller box by eliminating a part that is proved not to satisfy a constraint.

See the Applied Interval Analysis book by Jaulin et al. And the ibex-lib package.

[dpsanders]

Nonetheless it may still be simpler for now to separate the two concepts and avoid dependencies between packages.

[lucaferranti]

At least according to Jaulin book page 66 they seem to all be "just contractors". That is also in accordance with e.g. the wikipedia definition.

The concrete types of the different contractors are different, but I don't think that prevents them from having a shared abstract type.

A more practical issue is that at the moment the abstract contractors in the two packages are defined slightly differently
In IntervalRootFinding

abstract type Contractor{F} end

and in ICP

abstract type AbstractContractor end

so I guess the question is whether the common abstract type should be parametrized or not. At least based on the definition of BasicContractor in ICP, whose structure is very similar to Newton and Krawczyk in IntervalRootFinding, I would say the common abstract type needs not be parametric without too much harm? Or is there some performance advantage in having the abstract type parametric?