Interval set type

[schillic]

We need:

• multiply interval vs interval
• multiply interval vs scalar
• take Minkowski sum of interval and interval
• overapproximate (no-op)
• decompose

[mforets]

we can approach this by: treating a real interval as a numeric type, and the no-ops can be defined for scalars.

[schillic]

It is not clear to me what you mean by numeric type. Do we want to have BallInf{Interval}?
The no-op can simply be achieved by defining overapproximate(I::Interval) = I.

[mforets]

i mean to not add a new set type; just use them as scalars. all the operations of above work out of the box; the no-op is overapproximate(x::N) = x where {N <:Real}

[schillic]

But we call overapproximate for sets and the result needs to be a set again.

[mforets]

well, that is a problem of overloading functions names, overapproximate is doing nothing!

[schillic]

But the result for Reachability is a CartesianProduct of ... intervals, right? For this they must subtype LazySet.

[mforets]

ultimately we'll see if we hit some issue doing #74

[mforets]

But the result is a CartesianProduct of ... intervals, right? For this they must subtype LazySet.

point taken. let's do one LazySet extension (wrapper) around an existing interval arithmetic element 👍

[mforets]

type proposal:

@require IntervalArithmetic begin

import IntervalArithmetic.AbstractInterval

"""
    IA = IntervalArithmetic

Name alias for the interval arithmetic library.
"""
const IA = IntervalArithmetic

export Interval, IA

struct Interval{N, IN <: AbstractInterval{N}} <: AbstractPointSymmetricPolytope{N}
   dat::IN
end
# type-less convenience constructor
Interval{N, IN <: AbstractInterval{N}}(interval::IN) = Interval{N, IN}(interval)
# TODO: adapt show method

end

Questions:

• is subtyping AbstractPointSymmetricPolytope a good choice?

[schillic]

Looks good. It could also be an AbstractPolygon. Implementing AbstractPointSymmetricPolytope is simpler. Apart from that I do not see any arguments for one choice over the other.

[schillic]

What does dat stand for? Maybe just in or X?

[mforets]

Looks good. It could also be an AbstractPolygon. Implementing AbstractPointSymmetricPolytope is simpler.

yes, and actually dim(P::AbstractPolygon) = 2 so let's go for AbstractPointSymmetricPolytope.

What does dat stand for?

the field name with the data but we could use another name. should be used only internally.

[schillic]

Is dim(I::Interval) not 2?

[schillic]

Maybe import IntervalArithmetic.AbstractInterval to avoid the namespace stuff.

[mforets]

think about it as a unidimensional interval over the real line.

the definition in the library is:

abstract type AbstractInterval{T} <: Real end

struct Interval{T<:Real} <: AbstractInterval{T}
    lo :: T
    hi :: T

    function Interval{T}(a::Real, b::Real) where T<:Real

        if validity_check

            if is_valid_interval(a, b)
                new(a, b)

            else
                throw(ArgumentError("Interval of form [$a, $b] not allowed. Must have a ≤ b to construct interval(a, b)."))
            end

        end

        new(a, b)

    end
end

[schillic]

Oh, silly me, it is 1D of course 👍

[mforets]

i've updated the previous comment within @require block. that type can be used as

julia> using LazySets, IntervalArithmetic
INFO: Precompiling module LazySets.

julia> x = LazySets.Interval(IA.Interval(0.0, 1.0))

LazySets.Interval{Float64,IntervalArithmetic.Interval{Float64}}([0, 1])

what i dislike is that one needs to use the LazySets and IA at each time you create the object, but i don't see another approach.

[schillic]

You can define a type alias for each of them.

const IN = IA.Interval
const ITV = LazySets.Interval

But I agree that this is bogus.
Maybe also add a constructor that takes two numbers.

[mforets]

Maybe also add a constructor that takes two numbers.

that's a good idea.

[schillic]

And while you are at it, one from a vector :)